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ing  system  from  the  vantage  potfnt^of  current  and  future  support  requirements, 
addressing  the  AFGWC  data  processing  system  over  the  1977  through  1982  time 
frame.  This  study  was  performed  under  a unique  plan  which  allows  complete 
traceability  between  user  requirements.  Air  Force  Global  Weather  Central 
operational  functions,  requirements  levied  upon  the  data  system,  a proposed 
component  configuration  which  meets  the  data  system  requirements,  and  a system 
specification  designed  to  acquire  a system  which  meets  these  requirements. 


The  resultant  system  described  has  a number  of  unique  features,  including 
total  hardware  authentication  separation  of  security  levels,  load 
leveling  accomplished  by  assigning  main  processors  in  accordance  with  a dynamic 
priority  queue  of  tasks,  and  a system-wide  network  control  capability.  Other 
key  features  include  a central  data  base  processor  to  fill  requests  for  data 
from  other  processors,  computer  operations  centers,  the  use  of  array  processors 
for  accomplishing  difficult  numerical  problems,  and  sophisticated  forecaster 
console  support.  These  elements  have  been  designed  to  provide  99.5%  reli- 
ability in  meeting  user  requirements. 


The  proposed  system  architecture  consists  of  five  dual  processors  each  of 
which  is  about  3.5  times  as  powerful  as  an  existing  AFGWC  processor 
(a  Univac  1108).  Each  dual  processor  has  an  array  processor  which  will  be 
capable  of  very  high  performance  on  vector  arithmetic.  The  array  processors 
are  used  to  assist  on  the  difficult  numerical  probl ems,  including  the 
Advanced  Prediction  Model  for  the  global  atmosphere, as  well  as  very  fine  grid 
cloud  models  and  cloud  probability  models.  Some  of  the  new  requirements  that 
will  be  supported  with  this  system  are  a one  minute  response  to  query 
interface,  reentry  support  for  Minuteman,  and  limited  processing  of  high 
resolution  (0.3  nautical  mile)  meteorologica  satellite  data.  In  addition, 
cloud  cover  prediction  for  tactical  weapon  systems,  ionospheric  prediction 
for  radio  frequency  management,  and  defense  radar  interference  prediction  will 
be  supported  by  this  system. 


Volumes  of  this  final  System/Subsystem  Summary  Report  are  as  follows: 
Volume  1 - Executive  Summary 

Volume  2 - Requirements  Compilation  and  Analysis  (Parts  1,  2,  and  3) 
Volume  3 - Classified  Requirements  Topics  (Secret) 

Volume  4 - Systems  Analysis  and  Trade  Studies 
Volume  5 - System  Description 
Volume  6 - Aerospace  Ground  Equipment  Plan 
Volume  7 - Implementation  and  Development  Plans 
Volume  8 - System  Specification 
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ABSTRACT 


This  document  has  been  prepared  in  partial  fulfillment  of  CDRL  line  item  A004 
of  System  Development  Corporation's  Air  Force  Global  Weather  Central  System 
Architecture  Study  contract.  Efforts  for  this  report  were  expended  under  Task 
6,  "Conceptual  Design  and  Development  Plan",  performed  under  contract  F04701-75- 
C-0114  for  SAMSO,  under  the  direction  of  Col.  R.  J.  Fox,  YDA. 

The  purpose  of  this  study  has  been  to  optimize  the  entire  AFGWC  data  processing 
system  from  the  vantage  point  of  current  and  future  support  requirements, 
addressing  the  AFGWC  ds*-a  processing  system  over  the  1977  through  1982  time 
frame.  This  study  was  performed  under  a unique  plan  which  allows  complete 
traceability  between  user  requirements,  Air  Force  Global  Weather  Central  opera- 
tional functions,  requirements  levied  upon  the  data  system,  a proposed  component 
configuration  which  meets  the  data  system  requirements,  and  a system  specifica- 
tion designed  to  acquire  a system  which  meets  these  requirements. 

The  resultant  system  described  has  a number  of  unique  features,  including  total 
hardware  authentication  separation  of  security  levels,  load  leveling  accomplished 
by  assigning  main  processors  in  accordance  with  a dynamic  priority  queue  of  tasks, 
and  a system-wide  network  control  capability.  Other  key  features  include  a cen- 
tral data  base  processor  to  fill  requests  for  data  from  other  processors,  computer 
operations  centers,  the  use  of  array  processors  for  accomplishing  difficult  num- 
erical problems,  and  sophist. cated  forecaster  console  support.  These  elements 
have  been  designed  to  provide  99.5%  reliability  in  meeting  user  requirements. 

The  proposed  system  architecture  consists  of  five  dual  processors  each  of  which 
is  about  3.5  times  as  powerful  as  an  existing  AFGWC  processor  (a  Univac  1108). 

Each  dual  processor  has  an  array  processor  which  will  be  capable  of  very  high 
performance  on  vector  arithmetic.  The  array  processors  are  used  to  assist  on 
the  difficult  numerical  problems,  including  the  Advanced  Prediction  Model  for 
the  global  atmosphere,  as  well  as  very  fine  grid  cloud  models  and  cloud  proba- 
bility models.  Some  of  the  new  requirements  that  will  be  supported  with  this 
system  are  a one  minute  response  to  query  interface,  reentry  support  for 
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Minuteman,  and  limited  processing  of  high  resolution  (0.3  nautical  mile) 
meteorological  satellite  data.  In  addition,  cloud  cover  prediction  for  tacti- 
cal weapon  systems,  ionospheric  prediction  for  radio  frequency  management,  and 
defense  radar  interference  prediction  will  be  supported  by  this  system. 

Volumes  of  this  final  System/Subsystem  Summary  Report  are  as  follows: 

Volume  1 - Executive  Summary 

Volume  2 - Requirements  Compilation  and  Analysis  (Parts  1,  2,  and  3) 
Volume  3 - Classified  Requirements  Topics  (Secret) 

Volume  4 - Systems  Analysis  and  Trade  Studies 
Volume  5 - System  Description 
Volume  6 - Aerospace  Ground  Equipment  Plan 
Volume  7 - Implementation  and  Development  Plans 
Volume  8 - System  Specification 
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This  volume  contains  a descriptions  the  system/design  trade  studies  used  in 
developing  the  rationale  for  design  decisions  related  to  proposed  data  system 
architectures.  It  is  organized  according  to  major  data  system  components 
(Architectural  Domain)  referenced  in  the  Trade  Study  Report  Index.  Each  trade 
study  includes  data  dealing  with: 

a.  Applicable  requirements  and  background, 

b.  Design  p^proaches/characteristics, 

c.  Analysis,  and 

d.  Summary/conclusions. 

Tables  presented  in  the  first  portion  of  the  document  provide  reference  to  the 
linking  of  each  trade  study  to  both  key  system  requirements  and  system  specifi- 
cations. Each  trade  study  also  references  individual  system  specifications  of 
concern.  Appendix  A to  this  volume  contains  an  alphabetical  index  of  specific 
subjects  concerned  in  the  tradeoff  analyses. 
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SECTION  1.  DATA  STORAGE 

A10-1  What  is  the  distribution  of  various  types  of  storage? 

AlO-2  What  is  the  trade  between  rapid  data  transfer  versus  staging 

(especially  as  applied  to  tape)? 

A10-3  Are  there  applications  for  such  things  as  cassettes,  tape  reels, 
diskette,  and  floppy  disk? 

A10-4  What  is  the  backup/ recovery  approach  for  each  data  type? 

A10-5  Are  satellite  data  base  and  meteorological  data  base  different 
enough  to  warrant  different  memory  types  or  is  the  extra 
flexibility  desired? 


A10-6  Wha"  is  the  possibility  for  techniques  to  establish  satellite  data 
compression/rejection  criteria  with  interactive  meteorological 
verification? 

All-1  Is  multiple  simultaneous  data  base  update  from  several  processors 
warranted? 

All-2  How  will  control  be  accomplished  against  simultaneous  update  and 
read? 

All-3  What  is  the  output  spool  buffer  required  versus  the  number  of  devices 
(e.g.,  printers)? 


All -4 


Should  the  variable  perimeter  contain  storage  devices  that  are  not 
rapidly  cleanable,  or  should  this  processor  system  share  peripherals 
with  the  normal  access  and  special  access  areas? 


All -5  What  buffering  should  be  provided  in  communications  links? 


All-6  Should  a manual  or  automatic  mass  storage  system  be  selected? 
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All-7  Should  we  consider  the  10^  bit  associative  memory  (such  as  that 

being  developed  for  Rome  Air  Development  Center)  for  the  GWC  system? 

All-8  Can  a different  (e.g.,  cheaper)  medium  be  utilized  for  backup? 

A13-1  Is  there  an  advantage  to  a single  universal  data  base  with 
classified  overlays  instead  of  a data  base  for  each  system? 


A13-2  Is  the  master  data  base  hardware  different  from  the  "security 
level  associated"  data  bases? 

A13-3  What  is  the  tradeoff  between  data  compression  versus  uncompressed 
storage  for  satellite  data? 

A13-4  What  is  the  tradeoff  between  more  storage  area  and  data  packing  in 
the  meteorological  data  base  problem? 

A13-5  Should  discrete  satellite  data  storage  structure  be  used  for  analysis 
and  image  distribution  functions? 


A13-6  Should  WWMCCS  data  base  be  distinct  or  combined  with  general  data 
bases? 

A13-7  To  what  extent  should  application  programs  know  of  location  and 
structure  of  data? 

A13-8  Should  a distributed  data  base  concept  be  allowed? 

A13-9  Will  the  present  meteorological  data  base  structure  accommodate 

current  requirements  and  what  are  the  alternatives? 

A13-10  What  preformatting  of  data  can  be  accomplished  during  nonresource 
critical  periods  to  accommodate  faster  processing  at  run  time. 


m 1 Uhat  nonaral  i 70H  riata  ctnir turi nn  ic  warranted  (e.a.  . communications 


M 3- 1 2 What  are  the  data  base  complications  in  using  an  associative  processor 

for  data  management? 

M 3-1 3 Is  there  an  application  for  a Data  Management  System  produced  by  a 
vendor  (especially  consider  UNIVAC  1100  DMS)? 

413-14  Is  there  a need  to  record  access  and  usage  statistics? 

413-15  What  are  the  tradeoffs  between  a demand  versus  service  versus  update 

interface  with  the  central  unclassified  data  base? 

A13-16  Is  a data-oriented  language  warranted  for  use  at  AFGWC?  If  so, 
what  should  be  the  nature  of  the  language? 

SECTION  2.  DATA  TRANSFER  AND  ROUTING 

A20-1  How  does  intercommunication  take  place  within  the  GWC  architecture? 

A21-1  What  is  the  nature  of  a control -only  data  connection? 

A22-1  How  do  you  effect  one-way  communication? 

A22-2  How  will  authentication  be  used  for  the  "switching"  of  components 
within  the  data  system? 

A22-3  What  role  should  authentication  chips  and  switches  have  in  the  design? 

A24-1  Should  the  master  data  base  processor  transfer  data  to  the  requesting 

processor  or  directly  to  disk? 

A24-2  How  do  we  deal  with  incompatible  interfaces  and  what  will  be  the 
associated  costs? 

A24-3  Should  minicomputers  be  used  for  complex  incompatible  component 
interfaces? 

A29-1  Should  there  be  a total  system  protocol  for  devices? 

A29-2  What  should  be  established  for  satellite  data  reception,  processing, 
and  output  protocol? 


mm 
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COMPUTATION  AND  SOFTWARE 
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A30-1  What  is  the  tradeoff  between  heterogeneous  system  and  software  costs? 

A30-2  What  is  the  cost  of  interfacing  systems  from  two  vendors? 

A30-3  What  is  the  breakdown  of  an  average  GWC  function  into  wait, 

transfer,  and  compute  time  for  the  different  computer  sizes? 

A30-4  What  is  the  tradeoff  between  retaining  RTOS  along  with  required 
upgrades  and  starting  from  scratch? 

A30-5  What  is  the  minimum  number  of  a single  size  of  computer  required  to 
meet  GWC's  needs? 


A30-6  Based  on  an  assumed  configuration  mix,  determine  the  number  of 

processors  required  to  meet  the  GWC  workload  by  including  the  factors 
of  security  and  reliability. 
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A30-7  What  is  the  distribution  of  processing  according  to  the  highest 
classification  absolutely  required? 

A30-8  Should  we  utilize  single  Array  Processor  or  try  to  cp’iit  up 
the  problem  to  be  accomplished  on  several  processors? 

A30-9  Should  we  specify  special  array,  parallel,  or  associative 
processors  for  models? 

A30-10  What  is  the  tradeoff  between  using  separate  processors  for  special 
functions  or  part  of  a large  processor? 


A30-11  What  is  the  tradeoff  between  splitting  up  large  jobs  versus  more 
computer  power? 

A31-1  Can  multiprocessors  exist  under  the  security  requirements? 


A31-2 


Should  data  base  management  be  accomplished  on  a single  machine  or 
should  it  be  a time-shared  function  on  several  machines? 
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A31-3  Can  we  link  an  array  processor  to  more  than  one  host? 

A31-4  Can  network  control  and  central  data  base  management  have  their 
bullpen  backup  residing  on  the  same  multiprocessor  as  the  primary 
function? 

A31-5  Should  miniprocessors  be  used  for  tasks  like  nrinter  interface, 
console  interfaces,  and  communications  interface? 

A31-6  Should  there  be  several  processors  for  communications  or  a single  one 

A32-1  What  programmer  support  software  should  be  provided  (e.g.,  inter- 

active programming  language)? 

A32-2  Should  we  look  at  higher  order  languages  (e.g.,  analysis)? 

A32-3  What  is  the  tradeoff  between  dedicating  a function  to  a processor 
and  batched  processing  on  several  (i.e.,  consider  system  utiliza- 
tion, switching  and  program  availability)? 

SECTION  4.  TERMINAL  INTERFACE 

A40-1  What  is  the  splituo  of  functions  between  the  communications  system, 
communications  computer,  and  main  processor? 

A40-2  What  is  the  division  of  responsibility  between  the  1911th 
Communications  Squadron  (AFCS)  and  6WC? 

A40-3  Determine  the  cost  savings  and  security  impact  in  using  RTOS  in  a 
classified  machine  only  as  a router  of  lower  level  messages  to  a 
lower-level  configuration. 

A40-4  Should  message  logging  be  employed? 

A40-5  Should  query/response  interfaces  be  standardized? 

A40-6  What  maximum  rates  should  be  considered? 
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A40-7 


A42-1 

A43-1 


A43-2 


A43-3 


A43-4 


A44-1 


A44-2 

A44-3 


A44-4 


A44-5 


A44-6 


mrmeama 


What  approach  should  be  taken  to  editing  and  checking  of  outgoing 
messages? 


How  will  SWI  data  be  handled  in  the  proposed  architecture? 


Should  the  option  and  capability  exist  to  prefilter  satellite  data 
based  on  data-base  defined  and/or  user  time  criteria? 


Should  the  Satellite  Image  Dissemination  Subsystem  (SIDS)  interface 
be  a minicomputer,  normal  handling  of  tapes,  or  a direct  interface 
with  the  mapping  and  gridding  function  (imput  and  output)? 


Should  the  capability  exist  to  interface  raw  ungridded  data  with 
the  SID  interface? 


Should  satellite  data  be  gridded  and  mapped  on-the-fly  using  array 
processors  or  should  the  processing  continue  to  utilize  current 
techniques  and  an  upgraded  central  system  processing  with  buffering? 


What  is  the  tradeoff  between  the  user  of  one  large  communications 
processor  versus  several  small  ones? 


Should  priority  of  message  be  considered  in  processing? 


What  approach  should  be  taken  to  decode/checking  of  the  incoming 
data? 


Should  only  headers  be  certified  for  communications  data  or  should 
there  be  more  extensive  message-checking  capabilities? 


What  processor  configurations  should  be  used  for  the  line  handler/ 
decoder  routers? 


Should  packet  switching  capability  be  used  for  security/application 
routing? 


A45-1  To  what  extent  should  protocol  be  standardized? 
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A46-1 


Should  the  interface  with  all  facsimile  systems  be  the  Interdata  50? 


SECTION 

A50-1 

A51-1 

A51-2 

A52-1 

A52-2 

A52-3 

SECTION 

A70-1 

A70-2 

A71-1 

SECTION 

A81-1 

A81-2 


5/6.  CONSOLES/DATA  INPUT  AND  DISPLAY 

What  method  should  be  utilized  for  providing  and  updatinq  information 
to  the  AWC's? 

What  are  the  tradeoffs  associated  with  a centralized  operations 
console  versus  independent  ones? 

Should  we  consider  interactive  satellite  image  compression/ 
rejection  for  display? 

What  features  should  exist  in  the  forecast  console? 

What  is  the  tradeoff  between  alternative  programmer  interfaces 
with  the  data  system? 

What  is  the  tradeoff  between  storage  support  and  capability  for 
the  forecaster  consoles? 

7.  PERSONNEL 

How  can  the  shortage  of  qualified  Air  Force  programmers  be  alleviated? 

Should  programming  be  Air  Force  or  contractor? 

What  is  the  personnel  requirement  based  on  the  automated  work 
center  design? 

8.  MANAGEMENT 

Should  there  be  modifications  to  the  AFGWC  organizational  structure 
and  associated  responsibilities? 

What  is  the  level  to  which  operations  management  is  considered  in 
developing  the  network  controller  concept? 
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How  far  should  we  go  in  multitasking  - especially  a single  CPU? 

To  what  extent  should  functions  be  centralized  as  they  are  in  the 
current  operating  system? 

Should  automatic  scheduling  be  used  or  should  the  manual  mode  be 
continued? 

What  is  the  tradeoff  between  one  and  two  network  control  systems? 

What  is  the  tradeoff  between  the  benefits  of  exact  knowledge  of  task 
timing  and  the  amount  of  resources  needed  to  gather  that  knowledge? 

What  should  be  the  depth  of  responsibility  of  the  network  controller 
to  the  scheduling  of  processors  in  a multiprocessor  configuration? 

What  are  the  advantages  of  maintaining  the  lowest  security  levels? 

Are  more  than  two  levels  of  protection  required  within  the  normal 
access  perimeter? 

Shall  the  design  accommodate  a future  secure  operating  system? 

What  performance  measurement  software  is  required? 

How  will  phaseover  from  the  '77  baseline  to  the  new  data  system  be 
accomplished? 

What  is  the  requirement  for  system  usage  prediction/simulation? 

What  simulation  models  should  be  incorporated? 

How  are  present  software  development  techniques  to  be  brought  under 
a structured  programming  discipline  (e.g.,  modularization,  strict 
standards,  levels  of  abstraction,  etc.)? 
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A85-2  How  can  maintenance  of  existing  software  be  enhanced  and  new 
software  be  produced  more  effectively? 

A86-1  To  what  extent  should  hardware/ software  self-diagnostic  be  provideo? 

SECTION  9.  FACILITIES 

A93-1  Can  the  hardware  layout  of  future  computer  configurations  conform  to 
the  GWC  facility  space  available? 

SECTION  10.  COSTING 

AC1-1  What  cost  is  associated  with  the  hardware  and  software  in  the 
proposed  architecture? 

AC1-2  What  costs  are  associated  with  the  large  computational  requirements? 

ACL-3  What  is  the  software  cost  of  not  retaining  UNIVAC  1100  computers? 

AC1-4  What  is  the  cost  of  redundancy  in  configurations  where  the  variable 

perimeter  is  not  considered? 

AC1-5  What  is  the  cost  tradeoff  associated  with  an  automated  and  centralized 
network  control  capability 
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RELATIONSHIP  OF  VOLUME  STRUCTURE  TO  DOMAINS 


The  trade  studies  contained  in  this  volume  are  organized  according  to  an  augmen- 
ted version  of  the  architectural  domain  structure.  Trade  studies  in  Sections 
1.0  through  9.0  are  thus  categorized  in  pertinent  areas  of  this  domain;  e.g., 
Section  1.0  contains  topics  relating  to  Data  Storage,  Section  2.0  contains  Data 
Transfer  and  Routing  topics,  etc.  The  final  major  subdivision  of  the  archiec- 
tural  domain,  "Facilities,"  is  therefore  treated  in  Section  9.0  of  this  volume. 

In  addition.  Section  10.0  has  been  included  to  treat  aspects  of  costing,  which 
is  an  area  that  is  not  a specific  division  of  the  architectural  domain. 

The  traceability  to  the  architectural  domain  is  further  preserved  within  each 
section  of  this  volume  by  arranging  the  trade  studies  according  to  subdivisions 
of  that  domain.  For  example,  in  Section  1.0,  "Data  Storage,"  all  trade  studies 
numbered  All-X  are  associated  with  the  All  area  of  the  architectural  domain, 
"Storage  Devices."  In  some  cases,  no  trade  studies  have  been  made  for  specific 
categories;  e.g.,  the  absence  of  trade  studies  with  the  A12  prefix  indicate  that 
there  are  no  studies  associated  with  the  A12  segment  memory  of  the  architectural 
domain  (There  are,  however,  trade  studies  that  relate  to  processor  memories  under 
A31 , "Processors.")  Wherever  trades  of  a more  general  nature  are  treated  within 
a category,  these  are  contained  at  the  initial  portion  of  that  segment.  For 
example,  trade  studies  A10-1  through  A10-6  are  six  studies  each  of  which  encom- 
passes several  subtopics  under  the  Data  Storage  area. 
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INTRODUCTION 


0 

The  System/ Design  Trade  Study  Report  is  intended  to  supplement  the  System  Design 
Specification  and  the  Subsystem  Summary  Report.  It  provides  traceability  to  the 
requirements  (Requirement  Domain)  by  referencing  key  factors  involved  in  making 
the  tradeoff  decisions.  As  part  of  the  Subsystem  Summary  Report,  it  also 
references  directly  the  Design  Specifications  resulting  from  the  analyses. 
However,  the  referenced  specification  items  must  be  modified  after  the  specifi- 
cations are  finalized.  The  section  organization  is  the  same  (at  least  at  the 
top  level)  as  the  characteristics  imposed  by  the  requirements  (Characteristic 
Domain)  and  the  components  of  which  the  system  is  comprised  (Architectural 
Domain).  Within  sections  it  agrees  with  the  Architectural  Domain  which  will 
assist  in  providing  easy  reference  to  the  document  and  finding  rationale  used 
for  design  decisions.  Each  tradeoff  analysis  contains  a unique  number  to  be 
referenced  in  the  Design  Specifications  towards  the  same  end. 

Previous  versions  have  been  supplemented  with  an  introduction  to  each  section 
describing  briefly  the  current  state  of  the  design;  these  introductions  have 
been  deleted  since  this  document  is  now  part  of  the  Subsystem  Summary  Report. 

Following  this  introduction  is  the  Architectural  Domain  and  the  Trade  Study 
Report  Index.  An  alphabetical  index  is  also  provided  in  Appendix  A which 
allows  referencing  specific  subjects  in  the  tradeoff  analyses. 

To  provide  traceability,  a section  on  related  key  requirements  is  included  in 
each  trade  study.  In  addition,  an  overall  comparison  of  key  requirements 
versus  trade  studies  is  provided.  The  linkage  between  trade  studies  and 
specifications  is  provided  in  a central  table  in  the  front  of  the  document. 
Individual  specifications  are  also  referenced  in  each  trade  study. 
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TRADEOFF  TITLE 


3? 


AlO-1  What  is  the  distribution  of  various  types  of  storage? 


REQU I REMENTS/BACKGROUND 


Storage  can  be  considered  to  be  broken  up  into  four  types:  memory  (for  both 

conventional  and  array-type  processors),  fixed  head  disks  (small  capacity, 
fast  access),  disks  (moderate  capacity,  moderate  access),  and  mass-storage 
(large  capacity,  slow  access).  The  needed  amounts  of  these  different  types 
of  storage  must  be  determined. 

DESIGN  APPROACHES/CHARACTERISTICS 
(See  ANALYSIS) 

ANALYSIS 


. 


I 


a.  Memory  (Conventional  Processor) 

(1)  Specifications 

(a)  Required  for  Models: 

Approximately  two  (2)  million  characters/computer 
will  be  required  for  the  models.  This  estimate  is 
based  on  the  combined  size  of  the  largest  model  and 
the  operating  system.  The  following  table  lists 
numbers  of  computers  and  memory  sizes  which  will 
meet  the  requirements  of  the  models: 


computer 

# of  computers 

# char/main 
mem/comp 

# char/ext 
mem/comp 

IBM 

370/195 

6 

2,097,152 

— 

CDC 

CY-76 

6 

1,280,000 

640,000 

CDC 

STAR 

6 

2,048,000 

— 

( ) 


(b)  Required  for  remaining  functions: 

We  assume  5 1100/40  UNIVAC  dual  processor  computers 
(this  includes  1 for  backup)  can  fill  the  require- 
ment. These  machines  will  be  configured  at  their 
maximum  memory  of  524,288  words  main  and  1,048,576 
words  extended  memory.  Maximum  memory  for  these 
machines  is  a very  cost-effective  investment  and 
will  allow  for  easy  switching  of  major  functions. 

(2)  Summary 

For  the  models,  use  sufficient  main  memory  to  execute  the 
largest  model. 

For  the  other  requirements,  4 - 1100/40s  are  needed; 
these  will  also  handle  data  base  management,  network 
control,  and  act  as  hosts  for  array  processors.  This 
workload  justifies  maximum  memory  for  the  systems.  A 
5th  1100/40  is  needed  for  backup.  This  represents  a 
total  of  57  million  characters. 

Memory  (Array  Processor) 

(1)  Specifications 

Memory  sizing  for  the  array  processor  is  done  on  the 
basis  of  facts  and  assumptions  involving  the  Advanced 
Prediction  Model  (APM). 

The  APM  requires  a 2°  resolution.  (This  produces  a grid 
made  up  of  90  X 180  = 16,200  for  12  layers  in  the  atmos- 
phere. This  nay  be  reduced  by  up  to  30%  due  to  crowding 
of  the  grid  at  the  pole.  Thus  we  use  a factor  .7  to 
account  for  this  effect,  as  suggested  by  Smagorinsky. ) 


( ) 
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Forecasts  will  be  produced  for  data  base  storage  at  2-hour 
intervals  up  to  48  hours.  From  48  to  72  hours  the  storage 
interval  will  become  6 hours.  The  time  step  to  be  used 
in  the  solution  of  the  equation  will  be  one-half  an  hour. 


It  will  be  necessary  to  store  two  wind  components, 
pressure  height,  and  the  first  derivative  of  each  for  two 
points  in  time.  One  other  factor  is  a reduction  of  the 
grid  size  by  30%  as  suggested  by  Smagorinsky.  Finally, 
we  will  assume  only  one  atmospheric  level  will  be 
operated  on  at  a time. 

/time  \ /grid\  /SmagorinskyY:haracters\ 
(parameters)  \stepsj  \size/  \ factor  per  word  / 

6 X 2 X 16200  X .7  X 4 = 5.4  X 105  1 

characters-. 


(Note  that  in  the  above  calculation  each  word  is  being 
converted  to  four  characters.  Since  array  processors 
work  in  words,  not  characters,  this  is  not  a very 
meaningful  conversion.  It  is  done,  however,  to  keep 
the  result  consistent  with  other  storage  types.  The 
factor  of  "4"  is  based  on  the  32-bit  word  size  used  by 
most  array  processors.) 


Summary 

Data  vectors  require  4.5  X 10^  characters  of  memory  stor- 
age area.  Besides,  this  storage  is  also  required  for  I/O 
buffers  and  microcode  program  memory.  One  million 


characters  (10  ) is  therefore  reasonable  for  array 


processor  memory  requirements.  Since  there  are  five 


array  processors,  a total  of  5 X 10  characters  is  required. 


-V. 


c. 


Fixed  Head  Disks 

The  following  specifications  are  listed  as  a means  of 
comparing  the  relative  me^ts  of  competitive  storage  devices: 

(1)  Specifications 


unit 

capacity 

(char) 

access 

time 

transfer 

rate 

control 
unit  cost 

device 

cost 

432 

1.6M 

4.3ms 

1.4Mch/S 

$1 00K 

$ 50K 

1782 

12. 6M 

1 7 . Oms 

1.4Mch/S 

$1 00K 

$1 50K 

8405 

8.4M 

8 . 34ms 

622Kch/S 

$ 90K 

$ 80  K 

On  the  basis  of  the  above  table  the  8405  type  of  unit  is 
believed  to  be  the  most  cost  effective.  Four  of  this 
type  of  storage  device  will  be  needed  for  every  processor 
, system.  This  makes  a total  of  20  fixed-head  disks  and  a 
storage  capacity  of  168  million  characters. 

The  four  fixed-head  disks  are  separated  into  two  pairs  so 
that  each  half  of  a multiprocessor  (uniprocessor)  can  have 
its  own  fixed-head  disks.  Two  fixed-head  disks  are 
required  per  uniprocessor  for  reliability  and  for  use  by 
the  operating  system  and  numerical  models. 

(2)  Summary 

Fixed-head  disk  storage  will  consist  of  168  million 
characters.  This  will  include  an  area  for  the  operating 
system,  data  base  index,  and  roll  in/out.  All  these 
factors  will  be  new  additions  to  the  present  state  or 
will  increase  from  it.  The  8405  type  storage  is  picked 
since  it  represents  the  best  price/ performance  factor. 

d.  Disks 

The  following  specifications  are  listed  as  a means  of  compar- 
< ing  the  relative  merits  of  competitive  disk  storage  devices: 
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(1)  Specifications 


8440 

8433 

rotation  delay 

12.5ms 

8.3 

head  position  Lime 

30ms 

30 

transfer  rate 

138,700w/s 

179,117 

control  unit  cost 

$88,000 

$92,000 

device  cost 

$30,000 

$25,000 

capacity 

120Mchar 

200Mchar 

On  the  basis  of  the  above  data  the  type  of  unit  repre- 
sented by  the  8433  disk  is  believed  to  be  the  superior 
device  and  is  recommended  for  use  where  possible. 

The  following  table  itemizes  storage  requirements  of  GWC 
functions  on  disk  type  storage.  The  8433-type  disk  has 
been  used  whenever  possible  because  it  represents  the 
least  cost  per  bit.  For  raw  satellite  data,  the 
UNIVAC  8440  has  been  shown  because  GWC  is  building  a 
direct  interface  to  this  disk  for  satellite  ingestion 
and  because  the  8433- type  disk  has  too  much  data  under 
one  set  of  heads  for  good  performance  in  mapping  and 
gridding  of  raw  satellite  data.  For  disks  that  are  used 
as  communications  interfaces,  the  IBM  3340-type  disks 
have  been  shown  because  their  combination  of  fixed  and 
movable  heads  alleviates  access  conflicts;  these  have 
been  disked  as  "H/T  - M/H"  for  head  per  track  - movable 
head.  They  have  a capacity  of  approximately  70M  char- 
acters/pack  with  an  additional  .5M  characters  under 
fixed  heads. 


Table  1.  Disk  Type  Storage  Requirements 
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(2)  Summary 

The  8433  type  of  disk  is  preferred  since  it  represents  the 

latest  technology  and  has  the  best  price/performance  rating. 

A combination  of  disk  devices  including  this  type  will  oe 

g 

needed.  A total  of  5.7  X 10  characters  disk  storage  are 

required  for  basic  needs.  In  order  to  meet  reliability  re- 

g 

quirements  an  additional  2.09  X 10  characters  will  be 
required. 

e.  Mass  Storage  Facility 
(1)  Specifications 

The  mass  storage  facility  (MSF)  is  seen  as  a replacement  for 
the  present  magnetic  tape  storage  (see  All-6).  The  sizing  of 
the  storage  required  must  therefore  be  based  on  magnetic  tape 
usage  for  unclassified  storage. 


Normal  access  digital  computer  tapes 

programmer  save 

5,000 

needed  for  1982: 

Scratch  (6  day  save) 

600 

Mi  sc.  Save 

1,400 

Write  Protect 
Satellite  Save 

1,112 

Scratch 

200 

8,312 

Assuming  a 10%  utilization,  this  is  equivalent  to  831.2  full  tapes. 

Full  tape  capacity: 

C[;araC!erSyb-1-T-k  + .5  inch  IB6  = 10.8  inches/block 
1 ,600  characters/inch 

Single  tape  capacity  = 3'83  ^ncLs/block  X 16,536  ch/blk  = 4'3  X 10?  ch/taPe 
Total  storage  needed  = 4.3  X 10^  ch/tape  X 831.2  tapes  = 35.7  X 10^  character 
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Assume  70%  of  data  is  amenable  to  the  unclassified  MSP, 

.7  X 35.7  X 109  = 25  X 109  characters 

So  total  requirement  ~ 25  X 10®  + 8 X 10®  ETAC  f 2 X IQ®  (5*%  contingency) 

g 

si  35  X 10  characters 
g 

of  which  5 X 10  must  be  with  protected 

The  cost  of  a mass  storage  facility  providing  35  billion  characters  of  storage 
is  about  $.6  million. 

(2)  Summary 

This  inexpensive  storage  eliminates  manual  handling  of  tapes, 
and  maximizes  efficient  utilization  of  disks  by  paging  data 
sets  to/from  disk  on  demand. 

SUMMARY/CONCLUSION 

The  following  represent  the  requirements  for  the  different  types  of  storage  in 
characters: 

Memory  (conventional  )-  - - - * - - - — -12X10^  models 

45X1 0^  general  purpose 

Memory  (array)  — --------  — -5X1 0^ 

Fixed  head  disks  -----------  -1 68X1 0^ 

Disks ■ - - - ^ - - -7790X1 06 

Mass  Storage  -------------  -35,000X10^ 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 


*Not  as  high  for  MSF  as  for  1 0*5  inch  reel  tapes  since  more  efficient. 

G) 
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RELATED  SPECIFICATIONS 

AH  1-1  through  Alll-9,  A112-1  through  A112-9,  A113-1  through  A113-5,  A114-1, 
A115-1  through  A115-3,  A117-1  through  A117-22,  A121-1  through  A121-3,  A122-1 
through  A122-3,  A123-1,  AT 23-  through  A123-11,  A231-1,  A232-1  , A233-1  , A234-1 , 

A235-1,  A264-3,  4,  A312-16,  10,  A312-20,  21,  23,  24,  28,  32,  34,  G30-11  through 
18 
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TRADEOFF  TITLE 


AT 0-2  What  is  the  trade  between  rapid  data  transfer  versus  staging  (especially 
as  applied  to  tape)? 

REQUIREMENTS/BACKGROUND 

A computer  system  and  its  data  base  can  basically  rely  on  two  alternatives 
for  communication:  first  a direct  interface  which  relies  on  the  data  trans- 

fer rates  of  the  storage  device;  and  second,  staging  which  relocates  data  from 
a slower  to  a faster  storage  device  to  save  access  time  when  the  data  are 
needed  at  a later  point. 

DESIGN  APPROACHES/CHARACTERISTICS 

These  basic  approaches  have  been  considered  in  attacking  the  problem: 

a.  A direct  interface  between  CPU  and  the  storage  devices, 

b.  Staging  of  all  data  base  information  from  a slower  storage 
device  to  one  with  a faster  access  time,  and 

c.  A combination  of  direct  interface  and  staging  designed  to 
minimize  the  demand  on  system  resources,  make  maximum  use  of 
faster  access  times  of  some  storage  devices,  and  meet  all  time 
requirements. 

ANALYSIS 

The  concepts  of  direct  mass  storage  interface  and  staging  were  discussed  in  an 
Ampex  Terabit  memory  article  presented  at  SHARE  by  Erik  Salbu  on  6 March  1974. 
In  this  article  the  point  is  made  that  the  spectrum  of  mass-storage  system 
interface  approaches  can  De  divided  into  three  separate  classes:  specialized, 

shared  storage  devices,  and  device  emulation. 


"Most  of  the  early  attempts  at  mass  storage  systems  relied  on  a special  pur- 
pose interface  directly  between  the  host  CPU  and  the  MSS.  This  is  the 
easiest  to  build  from  a hardware  standpoint,  but  requires  the  host  CPU 
operating  system  to  be  changed  to  treat  the  MSS  as  a special  device  and/or 
the  user  programs  to  be  modified  to  properly  access  the  MSS  data. 

The  emulation  interface  also  involves  a direct  connection  between  the  host 
CPU  and  the  MSS.  However,  in  these  approaches  the  MSS  is  given  the 
sophistication  of  being  able  to  emulate  a standard  device  (tape  or  disk). 
This  tape  emulation  approach  is  primarily  applicable  to  those  applications 
involving  a relatively  small  number  of  large  sequential  files  since  random 
access  is  not  easily  supported.  The  most  general  and  desirable  approach  is 
probably  a disk  emulation  interface  in  which  the  MSS  acts  as  some  number  of 
disk  controllers  with  a trillion  bits  of  data  on  virtual  disk  devices. 
Unfortunately,  the  MSS  architecture  and  access  time  characteristics  to 
indicate  a continuation  preclude  this  type  of  interface  for  general  purpose 
installations. 

A reasonable  compromise  in  the  spectrum  of  interface  approaches  is  the 
concept  of  a shared  standard  device.  In  this  approach,  the  MSS  acts  as  a 
data  staging  controller  transferring  large  bursts  of  data  (data  sets)  to  a 
tape  or  disk  drive  which  is  shared  between  the  host  CPU  and  the  MSS.  This 
interface  has  the  same  advantage  as  the  emulation  interface,  i.e.,  the  host 
CPU  system  and  user  software  require  no  modifications  to  process  the  data." 

SUMMARY/CONCLUSION 

GWC's  needs  can  be  best  met  by  a combination  of  direct  interface  and  staging 
designed  to  minimize  the  demand  on  system  resources,  make  maximum  use  of 
faster  access  times  of  some  storage  devices,  and  meet  all  time  requirements. 
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RELATED  SPECIFICATIONS 

AT  17-1  through  A117-22,  A451-13,  G20-11  through  18 


(See  ANALYSIS) 


ANALYSIS 

These  devices  are  normally  used  in  keyed  data  entry  and  generally  have  no 
role  at  GWC.  The  exception  is  in  the  data  declassification  manual  interface 
where  a floppy  disk  shall  hold  the  data  prior  to  display  to  the  security 
monitor  and  communications  positions. 

SUMMARY/CONCLUSION 

The  security  downgrade  system  will  consist  of  a low  capacity  storage  device 
and  a completely  independent  (no  electronic  connection)  read  unit  which  allows 
a)  display  on  a CRT  to  a security  monitor;  b)  switchable  manual  routing  to  any 
classified  level  disk. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

409  - Environmental  Support  - Operational  Security 
416  - Environmental  Support  - Backup  to  Carswell 

RELATED  SPECIFICATIONS 

A118-1  through  A118-6,  A513-4  through  A513-8 
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TRADEOFF  TITLE 

A10-4  What  is  the  backup/ recovery  approach  for  each  data  type? 
REQUIREMENTS/BACKGROUND 

For  purposes  of  backup  the  data  base  can  be  considered  to  be  broken  up  into 
five  types: 

a.  Meteorological  data  (gridded  and  observational); 

b.  Overlay  data  bases; 

c.  Satellite  data  files; 

d.  Operating  system,  comm  libraries,  program  files,  and  other 
nontime  critical  data;  and 

e.  Archival  data. 

There  is  presently  a requirement  and  a procedure  for  backup  of  all  these 
data  types  with  the  exception  of  satellite  and  archival  data.  A decision 
must  be  made  on  what  will  be  considered  adequate  backup  in  the  future. 


DESIGN  APPROACHES/CHARACTERISTICS 

The  following  list  contains  the  primary  alternatives  considered: 


a. 


b. 


c. 


Have  no  backup  of  data  files  and  instead  reinitialize  the 
data  base. 


Continue  with  the  present  mode  of  backing  up  all  essential 
files  on  magnetic  tape  only. 

Purchase  enough  redundant  disk  and  drum  storage  so  that  some 
essential  data  base  files  can  be  backed  up  by  these  faster 
devices  when  necessary. 
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d.  Create  a backup  data  base  identical  in  all  ways  to  the  primary 
one  and  place  it  on  mass  storage  devices  identical  to  the 
primary  data  base. 

These  different  options  involve  different  hardware  costs  and  are  closely 
linked  to  the  configuration  of  the  primary  data  base.  Backup  requirements 
must  be  balanced  against  these  costs. 

ANALYSIS 

The  present  mode  of  data  base  backup  by  magnetic  tape  is  too  slow  and  limited 
in  its  access  capabilities  to  efficiently  back  up  the  larger  mass  storage 
devices  (such  as  the  UNIVAC  8433  disk  which  will  be  in  use  before  1982). 
Magnetic  tape  will  not  continue  to  be  an  adequate  backup  for  the  entire 
data  base.  More  specifically,  because  of  its  large  size  and  the  time  re- 
quired to  transfer  it  (both  to  and  from  tape),  the  gridded  and  observational 
data  base  will  need  to  be  backed  up  by  disks  identical  to  the  primary  storage 
devices.  The  same  arguments  hold  for  the  overlay  data  bases. 

Since  there  is  no  requirement  for  backup  of  the  satellite  files,  the  record- 
ing of  the  raw  data  in  the  satellite  data  receiving  area  (AP)  is  sufficient 
for  projected  needs. 

Some  files  which  do  not  change  with  short  periods  of  time  (like  the  operat- 
ing system,  comm  libraries,  and  program  files)  can  be  continued  to  be  backed 
up  by  magnetic  tape  since  the  files  do  not  need  to  be  reconstructed  as  often 
as  other  data  base  files  (one  tape  could  serve  as  a backup). 

Finally  we  consider  archival  data.  Since  these  data  only  were  constructed 
for  quality  control,  backup,  and  transmittal  to  other  facilities,  there  is 
no  need  for  recovery  procedures;  no  backup  is  needed. 
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SUMMARY/CONCLUSION 

Enough  redundant  disk  and  drum  storage  will  be  purchased  so  that  some  essential 
data  base  files  can  be  backed  up  by  these  faster  devices  when  necessary. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 


) 

1 


All  requirements. 


RELATED  SPECIFICATIONS 

A113-3,  A114-1 , A115-2,  A115-3,  A116-1,  A116-6,  A117-5,  A241-9 


9 

1 

1 
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TRADEOFF  TITLE 


AlO-5  Are  satellite  data  base  and  meteorological  data  base  different  enough 
to  warrant  different  memory  types  or  is  the  extra  flexibility  desired? 

REQUIUEMENTS/BACKGROUND 

The  function  and  origin  of  the  satellite  and  meteorological  data  bases  are 
sufficiently  different  so  that  they  may  each  warrant  unique  structures  or 

memory  devices. 

DESIGN  APPROACHES/CHARACTERISTICS 
(see  ANALYSIS) 

ANALYSIS 

The  types  of  memory  (storage)  devices  being  considered  for  data  base  storage 
have  only  included: 

a.  Fixed-Head  Disks  (low  capacity,  high  speed) 

b.  Disks  (moderate  capacity  and  speed) 

c.  Mass  Storage  (high  capacity,  low  speed) 

In  effect,  we  are  sufficiently  limited  in  our  choices  so  that  there  cannot  be 
much  variation  between  devices  used  for  meteorological  or  satellite  data  bases. 
(Variation  of  data  base  structure  is  an  issue  which  has  already  been  declared 
an  option  for  further  consideration.  See  Ai 5-9- ) 

SUMMARY/CONCLUSION 

Since  the  satellite  data  base  is  an  integral  part  of  the  central  data  base, 
the  design  of  the  central  data  base  has  already  determined  the  type  of  primary 
and  backup  storage  to  be  used  for  satellite  data. 


This  Trade  Study  is  related  to  the  following  requirements: 


113  - Special  Activities  - Program  D 
120  - Special  Activities  - ZOOM  Use 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 
A444-1 , A114-1,  A515-1  through  A515-4 
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TRADEOFF  TITLE 


A10-6  What  is  the  possibility  for  techniques  to  establish  satellite  data  com- 
pression/rejection criteria  with  interactive  meteorological  verification? 

REQUIREMENTS/BACKGROUND 

The  fully  automated,  reliably  consistent,  and  accurate  extraction  of  useful 
meteorological  phenomena  and  features  observed  in  presentation  of  remotely 
sensed  data  is  currently  beyond  the  state-of-the-art.  Criteria  for  automation 
have  not  been  established.  In  the  current  time  frame,  the  remotely  sensed  data 
are  presented  to  the  meteorologist  in  a pictorial  format,  either  on  a CRT  or 
more  commonly  on  photographic/facsimile  hardcopy.  The  existence,  recognition, 
and  identification  of  meteorological  characteristics  containing  useful  informa- 
tion are  manually  performed  by  a perusal  process  This  process  is  performed 
manually  for  both  static  and  dynamic  (i.e.,  time  dependent)  characteristics. 

In  the  latter,  time-lapsed  sequences  are  prepared  for  perusal  by  a meteorologist 
in  either  motion  picture  film  formats  (becoming  rapidly  obsolete)  or  by  refresh- 
ing a CRT.  The  determination  of  wind  vectors  from  cloud  motions  derived  from 
selected  cloud  locations  in  successive  GOES  data  frames  is  a current  technique 
exemplifying  the  use  of  time-lapsed  sequences  to  extract  information  from  dynamic 
meteorological  phenomena. 


DESIGN  APPROACHES/CHARACTERISTICS 

There  are  tv;o  basic  approaches  which  will  satisfy  this  problem: 

a.  Manual  extraction  of  meteorological  phenomena  from  hardcopy  displays, 

b.  Automated  evaluation  of  meteorological  phenomena  for  hardcopy  or  CRT 


presentation. 


ANALYSIS 


The  attainment  of  capabilities  for  fully  automated  extraction  of  useful  meteoro- 
logical information  from  remotely  sensed  data  would  be  a desirable  achievement. 
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An  ability  to  automatically  extract  pertinent  meteorological  information  would 
subsequently  enable  the  following  cost  conserving  advantages  to  accrue: 


Reduction  in  the  number  and  talent  level  of  required  meteorological 
operational  personnel  (including  their  training  cycle). 


b. 


Minimization  of  computational  growth  requirements  resulting  from 
elimination  of  data  that  do  not  contain  useful  meteorological  informa- 
tion (this  activity  is  closely  related  to  efforts  concerned  with 
development  of  data  rejection  algorithms  applied  during  the  initial 
data-stream  processing.  The  problems  of  data  compression  are  different 
from  those  of  data  rejection). 


c. 


Reduction  of  time  intervals  between  data  input  and  resulting  output  of 
significant  meteorological  information  to  enable  faster  turnaround 
where  meteorological  information  is  perishable  (to  either  the  end  user 
as  a product,  or  as  initial  condition  input  values  for  exercising 
numerical  analysis  or  forecast  models). 

To  achieve  automated  information  extraction  it  is  necessary  to  establish 
quantitative  criteria  and  to  then  invoke  numerical  pattern  recognition  and/or 
signature  analysis  principles,  probably  employing  both  structured  and  non- 
structured  techniques.  A meteorological  (numerical)  filter(s)  would  have  to  be 
developed  for  the  various  types  of  information  to  be  extracted  from  the  remotely 
sensed  data.  This  activity  can  be  significantly  enhanced  by  providing  a semi- 
automated  (i.e.,  interactive)  capability  for  the  learning  process.  Once  the 
filter  has  been  established  and  tested,  it  can  be  applied  to  the  operational 
data  stream  to  automatically  extract  the  meteorological  information  for  which 
it  was  designed. 


SUMMARY/CONCLUSION 

The  heuristic  capability  may  be  required  to  achieve  automated  meteorological 
information  extraction  capabilities  and  the  associated  long-term  operational 
cost-reduction  advantages. 
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A feasibility  analysis  and  methodical  development  of  techniques  and  capabilities 
is  required.  The  goal  in  the  architectural  design  is  to  accommodate  such  in- 
vestigations and  to  provide  a support  structure  for  possible  eventual  incorpor- 
ation of  resulting  capabilities.  The  results  of  the  study  will  not,  however, 
include  *ny  specific  recommendations  because  of  the  lack  of  time  to  accomplish 
any  of  the  required  data. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

120  - Special  Activities  - ZOOM  Use 
602  - General  - Manpower  Productivity 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


All-1  Is  multiple  simultaneous  data  base  update  from  several  processors 
warranted? 

REQUIREMENTS/BACKGROUND 

With  similar  functions  active  at  the  same  time  on  several  processors  there  is 
an  increasing  probability  that  multiple  data  base  updates  will  be  performed 
simultaneously.  Since  this  adds  significant  complication  to  the  system,  its 
necessity  should  be  evaluated. 

DESIGN  APPRQACHES/CHARACTERISTIf.S 
(See  ANALYSIS) 

ANALYSIS 

Simultaneous,  multiple  data  base  updates  from  several  processors  are  definitely 
warranted.  It  must  be  this  way  to  accommodate  the  network  control  concept  of 
distributing  functions  among  processors  to  obtain  optimum  system  efficiency. 

It  is  also  nt- ess ary  due  to  the  time-line  requirements  of  computing  functions. 

SUMMARY/CONCLUSION 

Allow  as  many  data  base  updates  to  occur  simultaneously  as  is  necessary  to 
satisfy  all  function  needs. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 

A131-1,  A132-1,  A132-4  through  A1 32-12,  A341-2 


All -2  How  will  control  be  accomplished  against  simultaneous  update  and  read? 


With  the  concept  of  a centralized  data  base,  control  must  be  accomplished  against 
simultaneous  update  and  read.  If  this  is  net  done,  the  "reader"  could  end  up 


with  a mixed  collection  of  both  new  and  old  data. 


DESIGN  APPROACHES/CHARACTERISTICS 

The  following  approaches  to  this  problem  have  been  considered: 

a.  Hardware  and  Executive  restraints  controlling  simultaneous  update  and 
reads. 

b.  Data  base  update  and  read  being  controlled  by  a central  data  base 
manager. 


ANALYSIS 

If  disks  are  accessed  directly  by  multiple  processors,  then  disk  control  unit 
hardware  queues  requests  for  accesses  to  the  same  physical  volume.  The  problem 
remains  of  how  to  avoid  thrashing  the  disk  due  to  head  motion  and  how  to  avoid 
discontinuity  due  to  update  while  processing.  The  only  answer  is  to  reserve 
data  sets  and  have  a convention  for  checking  the  data  set  status.  Executive 
functions  will  handle  the  problem  at  this  level.  If  reserve  becomes  necessary 
below  this  level,  blocks  can  be  reserved  on  a shared/exclusive  basis.  Most  new 
access  methods  have  this  capability.  With  a central  data  base  manager,  the  CPU 
acting  as  data  base  manager  will  queue  requests  and  reserve  resources.  Since 
the  design  of  the  data  base  now  calls  for  such  a manager  based  on  other  decisions, 
this  step  also  seems  logical. 
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SUMMARY/CONCLUSION 

The  ideal  solution  appears  to  be  a combination  of  both  design  approaches,  with 
data  base  update  and  read  being  controlled  by  a central  data  base  manager 
through  hardware,  executive,  and  protocol  constraints. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 
A341-2 


TRADEOFF  TITLE 


All-3  What  is  the  output  spool  buffer  required  versus  the  number  of  devices 
(e.g.,  printers)? 

REQUIREMENTS/BACKGROUND 

Given  a variable  amount  of  output  to  the  printer  with  time  it  must  be  decided 
whether  it  is  more  cost  effective  to  buy  more  printers  to  handle  the  job  or 
more  disks  to  buffer  to  the  printer. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  two  primary  alternatives  to  this  problem  include  procuring  more  printers 
to  handle  the  peak  load  or  purchasing  more  disk  storage  for  more  buffer  area 

for  output  to  printer.  A cost  study  must  be  performed  considering  these  two 
factors. 

ANALYSIS 

It  is  unlikely  that  problem  programs  can  drive  printers  at  efficient  speeds  due 
to  wait  times  for  data  access  and  computer  between  lines.  Also,  it  is  doubtful 
that,  in  the  GWC  environment,  a single  CPU  would  have  enough  printout  to  keep  a 
high-speed  printer  constantly  busy.  Since  a 2000-1 ine-per-minute  (LPM)  printer 
is  not  twice  as  expensive  as  a 1000  LPM  printer,  it  makes  sense  to  centralize 
and  to  buffer  printing.  Operator  efficiency  and  security  also  suggest  that  this 
is  a good  idea. 

What  we  need  to  know  is  the  size  of  disk  buffer  that  is  required  to  handle 
transients,  maintenance  down-time,  and  forms  changing  time.  If  we  assume  that 
reliability  dictates  duplicate  printers,  then  we  are  left  with  transients.  We 
can  probably  assume  that  a priority  system  allows  for  time  constraints  on 
products,  but  that  a backlog  of  ordinary  printout  can  build  up.  Printers  come 
in  fixed  speeds,  so  we  can  assume  that  GWC  will  buy  enough  to  handle  its 
problem  and  simply  calculate  buffer  size  as  a function  of  turnaround,  given  a 
printer  speed. 


CASE  1 . Given  an  IBM  3800  equivalent.  Assume  90%  efficiency  in  fitting  forms 
to  77"  drum.  Line  rate  is  then  0.9*  31.8  in^|s  * 100  y!j~  = 17,000 

Backlog  (hr)  Buffer  Size  (char)  200  X 10®  Char  Packs 

3 1.8  X 10®  0.9 

6 3.7  X 102  1.9 

9 5.5  X log  2.8 

12  7.3  X log  3.7 

24  14.7  X 10a  7.4 


These  figures  have  to  be  adjusted  for  the  fact  that  the  printer  will  be  unload- 
ing the  buffer  while  it  is  being  filled.  The  maximum  transfer  rate  to  disk  is 

5 

8 X 10  ch/sec.  At  a minimum,  it  would  take  225  seconds  to  load  a 3-hour  backlog, 
allowing  the  printer  to  output  3.8  X 10®  characters.  This  is  really  an  insigni- 
ficant result  in  view  of  the  total  and  in  view  of  the  discrete  size  of  storage 
in  100  X 10®  or  200  X 10®  character  packs. 

Case  2.  IBM  3211  equivalent.  Assume  90%  efficiency.  Throughput  = 0.9  * 2000 

LPM  * 100  ch/line  * * 3000 

du  sec  sec 


Backlog  (hr)  Buffer  Size  (char) 


(packs  G»  200  X 106  ch/pack) 


3 3.2  X 10  0.2 
6 6.5  X 104  0.3 
9 9.7  X 10B  0.5 
12  1.3  X 10g  0.7 
24  2.6  X 10°  1.3 


Cost  Analysis 

1 11,000  LPM  Printer  250,000 

1 2,000  LPM  Printer  100,000 

based  on:  UNIVAC  770  2000  LPM  CDC  580-20  2000  LPM 

$73,455  $102,060 
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1 - 200  X 106  character  disk  (given  controller)  = $40,000 

1 * 11,000  LPM  printer  - 6 packs  = 19.5  hour  backlog  for  this  device. 

1 * 2,000  LPM  printer  - 2.5  packs  > 24  hour  backlog  for  this  device. 

In  other  words,  given  that  you  can  handle  24  hours  of  printing  on  the  device  in 

the  steady  state,  it  is  cheaper  to  buy  disks  for  buffers  than  buy  another  printer 

to  cut  the  disk  load. 

The  only  reason  to  buy  more  printers  is  for  priority  work  or  additional 
throughput,  not  to  decrease  disk  buffer  size. 

The  number  of  disks  is  not  affected  by  security  constraints  because  one 
spooled  buffer  will  be  used  to  drive  several  printers  according  to  the 
security  classification  at  the  output. 

Three  types  of  printers  are  suggested  for  use  at  GWC  to  meet  requirements. 

Their  basic  difference  is  the  speed  at  which  they  operate:  1,000  LPM, 

2,000  LPM,  and  11,000  LPM.  The  following  tables  list  the  locations  and 
requirements  these  printers  will  fulfill: 


Printer 

Speed 

Normal  Access 
Perimeter 

Special  Access 
Perimeter 

Variable  Access 
Perimeter 

No.  Requirement 

No.  Requirement 

No.  Requirement 

1,000  LPM 

4 Maintenance 

and  backup 

1 Maintenance 

and  backup 

1 Maintenance 

and  backup 

2,000  LPM 

5 Routine  out- 

put for  four 
security 
levels  and 
backup 

1 Routine 

output 

11,000  LPM* 

2 Product 

Preparation 

- 

- 

♦Chosen  for  mechanism  which  permits  special  character  and  contours  rather 
than  for  the  high  print  speed.  This  prototypical  model  was  selected  because, 
as  the  most  expensive  selection  in  its  class,  it  results  in  a conservative 
cost  for  implementing  this  architectural  feature. 
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SUMMARY/CONCLUSION 

The  amount  of  buffer  required  to  support  spooled  output  should  be  consistent 
with  the  minimum  numbers  of  printers  required  to  support  peak  average  output. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 


RELATED  SPECIFICATIONS 
All  1 -2.  All! -4 


TRADEOFF  TITLE 
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All-4  Should  the  variable  perimeter  contain  storage  devices  that  are  not 
rapidly  cleanable,  or  should  this  processor  system  share  peripherals 
with  the  normal -access  or  the  special -ac< ess  areas? 


REQUIREMENTS/BACKGROUND 

The  processor  system  in  the  variable-access  perimeter  is  intended  as  a backup 
system  for  both  the  special-access  and  normal-access  perimeters. 


DESIGN  APPROACHES/CHARACTERISTICS 


The  tradeoff  in  this  case  is  between  the  difficulty  of  cabling  the  variable 
access  perimeters  to  two  external  peripheral  sets  versus  having  peripherals 
inside  the  variable  access  perimeter.  Because  disks  are  not  rapidly  cleanable, 
they  could  delay  switching  of  the  variable-access  perimeter  from  the  special 
access  mode  back  to  a normal -access  mode. 


ANALYSIS 


Because  the  variable-access  perimeter  processor  system  acts  as  a backup,  when 
it  is  used  it  will  normally  be  assuming  the  role  of  a failed  processor  or  of 
a processor  which  will  be  taken  for  preventative  maintenance.  Hence,  all  of 
the  data  base  information  it  needs  to  do  its  work  will  be  contained  on  disks 
located  either  inside  the  special-access  or  inside  the  normal-access  perimeters. 
The  variable-access  perimeter  processor  will  not  need  disks  or  tapes  in  its 
own  area.  Placing  disks  or  tapes  in  its  own  area  could  result  in  a higher 
probability  of  security  violation  due  to  the  fact  that  such  disk  packs  or 
tapes  would  have  to  be  removed  to  make  a transition  from  running  special 
access  to  running  in  normal -access  mode. 


SUMMARY/CONCLUSION 


The  variable  access  perimeter  shall  contain  only  rapidly  cleanable  devices, 
e.g.,  the  array  processors,  main  memory,  and  fixed-head  disks. 
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TRADEOFF  TITLE 

AT  1 - 5 What  buffering  should  be  provided  in  communications  links? 


REQUIREMENTS/BACKGROUND 

Communications  links  into  AFGWC  will  be  handled  by  front  end  devices  called 
line  handler/decoder  routers  {LHDR) . The  LHDRs  will  have  to  have  sufficient 
buffering  to  ensure  that  they  can  handle  peak  load  transients  and  that  they 
can  store-and-forward  messages.  In  addition,  buffering  should  be  provided 
between  the  communications  links  and  the  remainder  of  the  data  system  to  allow 
processors  within  the  data  system  time  to  be  upgraded  for  security  reasons  or 
to  respond  in  a prioritized  order  to  messages.  It  should  be  noted  that  the 
LHDRs  are  not  actually  part  of  AFGWC,  bu*;  rather  belong  to  the  communications 
squadron.  Hence,  the  concern  of  this  tradeoff  study  is  not  so  much  with  the 
design  of  the  LHDR  and  its  associate  peripherals,  as  it  is  with  the  interface 
to  the  Global  Weather  Central.  The  tradeoff  analysis  concerns  itself  with  the 
internal  structure  of  the  system  of  LHDRs  only  as  it  pertains  to  and  effects 
that  interface. 

DESIGN  APPROACHES/CHARACTERISTICS 

If  the  LHDRs  were  interfaced  on  a computer- to-computer  basis  with  the  remainder 
of  the  AFGWC  data  system,  they  would  require  their  own  disks  for  buffering.  How- 
ever, this  direct  computer-to-computer  interface  is  not  desirable  in  the 
enhanced  architecture  because  of  the  following  reasons: 

a.  Processors  within  the  data  system  may  not  necessarily  be  at  a 
security  level  compatible  with  an  LHDR,  hence,  buffering  is 
required  in  between  the  LHDR  and  the  data  system. 

b.  Network  Control  must  manage  the  scheduling  of  functions  within  the 
data  system  to  meet  deadlines  and  priorities.  Therefore,  lower 
priority  messages  may  back  up  between  the  LHDRs  and  the  remainder 
of  the  data  system. 
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c.  Processor- to-processor  cabling  is  more  constrained  (i.e.,  must 

have  shorter  cables)  than  processor-to-disk-to-processor  communications. 

d.  The  disks  on  the  LHDRs  would  be  an  additional  expense. 

e.  Switching  of  CPU-to-CPU  channel  speed  communication  is 
dangerous  in  that  it  has  the  potential  of  causing  errors  that 
would  bring  both  CPUs  down. 

ANALYSIS 

The  LHDRs  should  be  interfaced  to  disk  subsystems  of  the  AFGWC-enhanced 
architecture  rather  than  directly  to  processors.  The  only  difficulty  in 
doing  this  is  to  overcome  the  potential  bottlenecks  of  having  processors 
within  the  AFGWC  data  system  accessing  messages  placed  on  disks  by  LHDRs 
attached  to  communications  lines.  This  potential  bottleneck  can  be  overcome 
by  using  the  multiple  disk  packs  for  the  data  sets  and  providing  alternate 
paths  to  the  disk  packs  through  control  units  and  switches.  Also,  the  nature 
of  the  disk  packs  themselves  can  be  optimized  for  rapid  retrieval  of  data, 
i.e.,  they  can  be  a mixture  of  fixed  and  movable  head  disks  such  as  the  IBM 
3340.  For  the  IBM  3340,  the  first  five  cylinders  or  so  ?re  accessed  via  fixed 
heads  while  the  remainder  are  accessed  via  movable  heads.  This  arrangement  is 
also  convenient  for  store-and-forward  messages  which  will  be  accessed  solely 
by  the  LHDRs.  The  volume  of  storage  supplied  by  five  cyclinders  of  the  3340 
is  approximately  .5  million  characters  per  pack,  which  is  more  than  enough 
storage  for  the  store-and-forward  messages  handled  by  LHDRs. 

SUMMARY/CONCLUSION 

The  only  buffering  provided  in  communications  links  in  the  enhanced  architec- 
ture will  be  that  of  system  disks.  The  nature  of  the  system  disks  should  be 
such  as  to  prevent  a bottleneck  in  the  accessing  of  messages  within  the  data 
system  and  the  pacing  of  messages  on  the  disks  by  the  LHDRs.  To  prevent  such 
bottlenecks,  multiple  disk  packs  should  bemused  to  spread  data  sets  over  as 
many  access  arms  as  possible,  and  multiple  control  units  with  multiple  ports 
should  be  used  on  a string  of  disk  packs.  Furthermore,  the  disks  themselves 
should  be  of  a nature  that  have  both  fixed  and  movable  head  areas  on  them. 
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RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements 
All  requirements. 


RELATED  SPECIFICATIONS 


A40-1 , A451-13,  All 3-1,  through  3 
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TRADEOFF  TITLE 


All -6  Should  a manual  or  automatic  mass  storage  system  be  selected? 
REQUIREMENTS/BACKGROUND 

Some  automatic  storage  devices  do  not  require  the  personnel  associated  with 
their  manual  counterparts.  The  result  then  is  a savings  in  manpower  and  a 
possible  cost  savings  overall.  The  savings  in  personnel  is  especially  attrac- 
tive at  GWC  which  will  undergo  no  manning  increase  while  requirements  for  new 
products  continue  to  rise. 

DESIGN  APPROACHES/CHARACTERISTICS 

There  are  two  possible  areas  of  application  for  this  concept  at  GWC: 

a.  All  storage  internal  to  GWC  which  is  now  done  on  magnetic  tapes  can 
instead  use  a mass -storage  facility; 

b.  Storage  which  must  continue  to  use  the  magnetic  tape  medium,  such 
as  that  which  will  be  sent  to  a customer  external  to  GWC,  is  a 
candidate  for  an  automated  tape  library. 


ANALYSIS 


The  replacement  of  conventional  tape  devices  for  unclassified  applications  would 
replace  two  tape  hangers/shift  or  a total  of  10  individuals.  The  burdened  rate 
for  these  is  about  $25, 000/year  for  a total  gross  savings  of  $250, 000/year. 

The  IBM  3850-B1  mass  storage  facility  rents  for  $16, 333/month,  leading  to  an 
annual  cost  of  $195,996. 

The  Calcomp  tape  library  is  much  less  expensive.  Its  monthly  rental  on  a 1- 
year  lease  (GSA)  for  a redundant  system  of  2 LCUs,  4 LSUs  is  $78,480.  An 
additional  one-time  cost  involves  the  software  interface  between  the  Calcomp 
machine  and  UNIVAC  hardware.  The  Census  Bureau  is  currently  developing  such 
software  for  their  own  use  but  it  will  not  be  supported  by  Calcomp.  SDC  estimates 
that  Calcomp  could  provide  fully  supported  software  at  a one-time  cost  of  about 
$100,000. 
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Total  replacement  of  the  personnel  involved  in  tape  hanging  would  require  the 
acquisition  of  both  a mass-storage  facility  and  an  automatic  tape  library  at 
a cost  which  approximately  equals  the  savings. 

SUMMARY/CONCLUSION 

There  is  a definite  application  for  an  automatic  mass  storage  system  at  GWC. 
RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

602  - General  - Manpower  Productivity 

409  - Environmental  Support  - Operational  Security 

RELATED  SPECIFICATIONS 

All 7-1  through  All 7-22,  G30-11  through  18 


TRADEOFF  TITLE 


( 
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All -7  Should  we  consider  the  109  bit  associative  memory  (such  as  that  being 
developed  for  Rome  Air  Development  Center)  for  the  GWC  System? 


REQUIREMENTS/BACKGROUND 


Rome  Air  Development  Center  is  funding  development  of  a 109-bit  associative 
memory  to  augment  their  STARAN  for  data  base  applications. 


DESIGN  APPROACHES/CHARACTERISTICS 
(See  ANALYSIS) 


ANALYSIS 


In  our  time-frame  the  technology  would  serve  to  enhance  the  capabilities  of  an 
associative  processor.  We  cannot  count  on  it  being  available,  however. 


SUMMARY/CONCLUSION 


GWC  should  monitor  the  progress  of  this  technology  through  Rome  Air  Development 
Center. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

218  - Command  Control  Systems  - Computer  Flight  Plans 
305  - Emergency  War  Order  Support  - SAC 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 
511  - Space  Environment  Support  - OTHB  Radar 


RELATED  SPECIFICATIONS 

There  are  no  specification  items  pertinent  to  this  conclusion. 


RELATED  SPECIFICATIONS 
None 
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TRADEOFF  TITLE 


All-8  Can  a different  (e.g.,  cheaper)  medium  be  utilized  for  backup? 


REQUIREMENTS/ BACKGROUND 


Because  of  the  size  and  complexity  of  GWC's  data-base  backing,  it  up  can  be  an 
expensive  problem.  A different  approach  is  to  use  a cheaper  medium  for  backup. 


DESIGN  APPROACHES/CHARACTERISTICS 


Provided  that  cheaper  mediums  of  storage  can  meet  speed  requirements,  two  of  the 
prime  candidate  devices  are  magnetic  tape  or  a mass-storage  facility  (101 °-bit 
capacity) . 


ANALYSIS 


A typical  mass-storage  facility  holds  approximately  35.3  x 109  characters,  or 
about  170  disks  worth  of  data.  If  it  could  be  used  as  a backup  (e.g.,  meets 
access-time  criteria)  it  could  quickly  pay  for  itself. 


An  example  is  the  satellite  data  base  which  will  require  a total  backup  of  about 


200  x 106  words  by  1982,  or  1.2  x 109  characters.  The  cost  of  disks  to  store 


these  data  is  about  2/3  the  price  of  a mass  storage  facility.  But,  in 
addition  to  this  backup,  the  mass-storage  facility  could  also  be  used  to  store 
raw  satellite  files,  saving  additional  disk  space  and,  therefore,  more  memory. 


SUMMARY/CONCLUSIONS 


The  mass-storage  facility  may  be  a feasible  alternative  medium  for  backup  but 
should  still  be  carried  as  an  option. 


/ 'i 

I 


TRADEOFF  TITLE 
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A13-1  Is  there  an  advantage  to  a single  universal  data  base  with  classified 
overlays  instead  of  a data  base  for  each  system? 

REQUIREMENTS/BACKGROUND 

The  data  base  is  primarily  made  up  of  observational,  grldded  meteorological,  and 
satellite-sensed  parameters.  It  is  the  storage  location  of  the  primary  input 
and  output  fields  used  by  the  GWC  analysis  and  forecasting  functions.  The  basic 
structure  of  this  data  base  therefore  has  a definite  impact  on  the  computer 
resources  required  by  these  key  GWC  functions  and  should  be  designed  accordingly. 

DESIGN  APPROACHES/CHARACTERISTICS 

Because  of  the  nature  of  the  meteorological  data  base  ( 1 . e . , size,  structure 
complexity,  and  requirement  for  random  access),  disks  are  the  best  storage 
alternative.  The  capability  will  be  present  (because  of  the  existence  of  the 
one-way  data  line)  to  upgrade  data  from  the  unclassified  data  base  to  any 
higher  level. 

The  present  data  base  design  allows  for  essentially  duplicate  data  bases  on 
each  of  the  component  computer  systems  which  comprise  GWC.  An  alternative 
approach  is  to  have  less  redundancy  and  more  centralization  in  the  data  base 
design.  This  would  call  for  one  processor  acting  as  a data  base  manager 
controlling  the  simultaneous  use  of  the  data  base  by  the  other  processors.  The 
central  data  base  could  be  complemented  by  additional  classified  overlays  on 
the  individual  systems  when  required  by  security  considerations. 

In  eliminating  the  data  base  redundancy,  the  large  data  base  plan  also  reduces 
the  number  of  storage  devices  needed.  The  one  data  base,  being  accessed  by 
processors  of  varying  classifications  does  present  a security  problem;  however, 
this  problem  would  be  solved  with  the  use  of  control -only  data  links  between 
the  unclassified  central  data  base  and  processors  of  a higher  security  level. 
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ANALYSIS 

With  several  meteorological  satellites  (DMSP,  GOES,  and  TIROS)  and  with  more 
sources  for  data  {including  radar  data),  the  update  of  the  data  base  will  not 
necessarily  be  on  a 3-hour  (or  any  other)  period.  In  fact,  1985  require- 
ments dictate  the  assumption  of  data  availability  to  update  the  meteorological 
data  base  on  a sporadic  (and  for  the  most  part  almost  continuous)  time  scale. 
Data  base  updates  based  on  requirements  and  time  limitations  necessitate  up- 
dating of  universal  data  bases  on  the  order  of  10  minutes  or  less.  The  total 
transfer  of  data  is  an  expensive  requirement  in  terms  of  resources  used.  We 
propose  the  alternative  where  data  are  not  necessarily  duplicated  from  the 
master  data  base  but  rather  all  processors  have  access  to  a universal  data  base. 
One  of  the  principal  reasons  for  not  doing  this  in  the  past  is  that  the  updating 
of  this  information  by  forecasters  may  impart  information  which  is  classified 
because  of  time  and  position.  The  solution  as  we  see  it  is  the  existence  of  a 
classified  data  base  which  retains  information  updated  by  the  forecasters  which 
in  effect  acts  as  an  overlay  to  the  universal  data  base.  As  far  as  the  user 
programs  are  concerned,  they  are  accessing  a single  data  base,  and  other 
users  operating  at  the  same  classification  level  can  receive  the  same 
information.  In  fact,  the  classified  data  base  is  small  so  excess  time  will 
not  have  degraded  the  system  and  a significant  amount  of  resource  has  been  saved. 

One  problem  has  been  accessing  data  without  betraying  the  location.  We  feel 
that  the  globe  can  be  partitioned  (e.g.,  WAC  charts)  and  the  data  can  be  re- 
quested via  control-only  data  links  using  the  code  which  identifies  one  part 
in  512  (2  in  terms  of  bits  passed  from  a higher  level  computer  with  the  actual 
protection  of  hardware  for  the  actual  access  to  the  master  data  base). 

An  overlay  is  dependent  upon  the  explicit  link  between  geometric  3-space  and 
the  data  base  structure.  Until  this  relationship  is  established,  we  won't 
know  precisely  how  the  overlays  work.  If  the  relationship  can  be  determined 
a priori,  then  there  will  be  a table  established  which,  with  knowledge  of  the 
order  of  transmission  of  data,  identifies  portions  of  the  data  base  to  be 
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substituted  for  what  is  being  transferred.  This  table  then  points  to  the  new 
data.  Whether  each  new  data  set  has  to  be  checked  for  substitution  or  whether 
some  intelligence  can  be  employed  to  the  arrival  time  of  the  key  data  again 
depends  on  the  structure  and  the  predictability  of  the  arrival  of  the  data. 

At  some  level  it  should  be  predictable,  but  not  necessarily  at  the  individual 
grid-point  level . 

Compared  to  the  size  of  the  total  meteorological  data  base,  the  overlay  portion 
is  deemed  to  be  fairly  small.  If  it  results  from  classified  data  input,  it 
might  be  as  much  as  5%,  but  if  it  results  from  manual  corrections,  it  will  be 
extremely  small. 

SUMMARY/CONCLUSION 

A single  universal  data  base  will  be  used  which  each  computer  system  can  access. 
Classified  overlays  will  be  used  for  a computer  system  based  on  security  re- 
quirements. This  design  will  require  a minimum  number  of  mass-storage  devices 
compared  to  the  present  redundant  data  base  concept.  Each  processor  will  have 
access  to  the  data  base  either  through  two-way  communication  lines  or  a one-way 
communication  line  plus  control  data  line  depending  on  the  security  level. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 

A131-2,  3,  7,  8,  A132-1 , 4,  5,  7,  11,  14,  A261-1  (e,  k),  A341-3,  A931-1,  A251-1 
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TRADEOFF  TITLE 


A13-2  Is  the  master  data  base  different  hardware  than  the  "security  level 
associated"  data  bases? 

REQUIREMENTS/BACKGROUND 

It  has  been  decided  that  the  central  data  base  will  be  augmented  by  several 
classified  overlays.  While  the  central  data  base  will  be  available  for  access 
by  all  processors,  a classified  overlay  will  be  available  only  to  systems  of 
the  same  level  as  the  system  which  built  it.  Because  of  the  bulk  nature  of 
the  classified  data  base,  it  may  warrant  different  hardware. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  design  of  the  data  base  has  been  considered  by  A10-1. 

ANALYSIS 

The  question  here  pertains  to  the  bulk  nature  of  the  master  data  base  and 
the  fact  that  input  to  that  data  base  will  be  in  large  data  quantities. 
Contradistinctively,  the  classified  data  bases  have  multiple  users  with  short 
messages  and  cyclic  storage  areas  for  communications.  There  is  a good  chance 
that  a combination  of  fixed  and  variable  head  disks  would  be  appropriate  tor 
the  classified  data  bases  but  not  for  the  master. 

SUMMARY/CONCLUS ION 

A master  data  base  will  be  on  disks  augmented  by  a mass-storage  facility. 
Overlays  to  this  data  base  will  be  established  on  disks  at  the  appropriate 
security  level. 
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RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special  Activities  - All 

300  - Emergency  War  Order  Support  - All 

511  - Space  Environment  Support  - OTHB  Radar 


RELATED  SPECIFICATIONS 


A113-3,  A115-1 , A233-1  , A235-1 
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Satellite  data  are  presently  mapped,  gridded,  and  stored  in  the  data  base  on  a 
1 /64th  mesh  grid  (3  nautical  miles  on  a side).  The  information  is  "packed  so 
that  six  grid  points  are  contained  in  each  36-bit  word.  As  the  requirements  for 
processing  more  and  more  satellite  data  increase,  so  does  the  amount  of  mass 
storage  it  takes  to  contain  these  data.  Another  factor  is  the  requirement  for 
processing  of  higher  resolution  satellite  data  which  will  require  even  more 
storage  space.  Design  alternatives  which  would  reduce  the  amount  of  mass  storage 

needed  should  be  investigated. 

i 

DESIGN  APPROACHES/CHARACTERISTICS 

The  relative  value  of  raw  data  compression  versus  the  direct  storage  of  raw 
data  is  addressed  in  this  analysis. 

>1 

The  following  assumptions  and  approaches  will  be  used  ih  this  study: 

a.  The  bulk  of  this  discussion  will  treat  "data  compression"  as  compression  j 
for  the  purposes  of  data  ingest  storage.  Data  compression  techniques 
associated  with  various  techniques  of  pattern  recognition  will  be  handled  ^ 
in  a far  more  qualitative  manner. 

b.  This  tradeoff  assumes  the  use  of  double  density  disk  units  that  will 
store  aoproximately  34  million  (36  bit)  words,  e.g.,  UNIVAC  8433  disk 
unit,  although  it  is  recognized  that  other  disks  are  also  candidates. 

c.  Raw  data,  once  ingested  for  a specific  vehicle,  will  be  gridded  and 
mapped  prior  to  the  next  contact  with  the  same  vehicle. 

d.  Total  real-time  conflicts  can  exist  within  a program.  For  example, 
two  DMSP  vehicle  contacts  can  occur  in  exact  time  coincidence. 


e.  Current  Site  III  or  satellite  relay  capabilities  were  not  considered  to 
be  limiting;  i.e.,  the  vehicle/AFGWC  interface  is  working  at  optimum 
efficiency  and  the  equipment  in  that  interface  is  transparent  to  the 
AFGWC  data  system.  (In  the  Block  5D  era  this  would  imply  two  2.66 

mbs  links  from  each  remote  site.) 

f.  Vehicle  orbit  parameters  are  approximately  assumed  for  1)  DMSP  vehicles 
flying  for  early  morning  and  noon  area  crossings  and  2)  TIROS-N  flying 
for  mid-morning  and  mid-afternoon  area  crossing.  (This  precludes  the 
occurrence  of  simultaneous  "major  blind"  readouts.) 


ANALYSIS 

The  alternative  to  storing  the  satellite  data  in  their  present  uncompressed  form 
is  to  go  to  some  compression  technique  (like  a Fourier  Analysis)  and  store  only 
representative  parameters  in  the  data  base.  Besides  allowing  for  a reduction  in 
mass  storage  area  needed,  these  "compression"  parameters  may  have  other  direct 
applications  to  cloud  analysis,  thus  having  other  favorable  effects  on  computer 
resources. 

More  than  reducing  data  storage  space,  the  compression  statistics  may  prove  very 
useful  in  enhancing  automated  cloud  analysis  techniques.  The  work  of  Captain 
Sikula  at  GWC  indicated  that  a compression  rate  of  100-to-l  could  be  achieved 
with  the  necessary  cloud  information  still  retained.  There  are  two  problems 
with  applying  Captain  Sikula' s work  too  quickly  to  the  GWC  situation: 

a.  Much  costly  development  work  is  still  left  to  be  done  in  the  area  of 
relating  satellite  data  compression  statistics  to  cloud  parameters; 

b.  Since  the  compressed  data  will  be  used  for  other  analysis  models  (snow 
and  temperature  for  example)  as  well  as  displays,  a compression  technique 
suitable  only  for  a cloud  analysis  cannot  be  employed.  It  is  estimated 
that  the  kind  of  general  compression  rate  GWC  could  more  likely  obtain 

is  4 to  1 . 
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This  qualitative  discussion  will  now  be  followed  by  a detailed  five-part  study 
of  the  costs  involved  in  storing  and  compressing  satellite  data  at  GWC. 

DMSP 

The  maximum  expected  single-station  readout  will  occur  when  a vehicle 
exits  its  "major  blind"  which  occurs  between  daily  revolutions  1 and  6. 

At  a maximum,  this  will  cover  four  revolutions  or  approximately  400 
minutes  of  data  (one  full  record)  recorded  in  the  smoothed  mode  and  20  to 
40  minutes  of  fine  data  (one  full  record).  This  can  occur  with  a real- 
time conflict  of  the  second  DMSP  vehicle.  The  second  vehicle  would  be 
reading  out  100  minutes  of  smoothed  data  and  20  to  40  minutes  of  fine  data. 

a.  Vehicle  1 (Major  Blind  Exit) 

1.  Smoothed  Data 

Number  of  36  bit  words/readout  = 2.66  mbs  X 60  sec/mi n X 2.5  min 
per  orbit  of  data  X 4 orbits  X 0.86  (Data  Formatter  conversion 
factor)  * 36  bits  per  word. 

Total  = 38  X 10®  words/readout 

2.  Fine  Data 

Number  of  36  bit  words/readout  = 2.66  mbs  X 60  sec/mi n X 10  min 
of  transmission  time  X 0.9  (Data  Formatter  conversion  factor) 

* 36  bits/word. 

Total  - 39.9  X 10®  words/readout 

b.  Vehicle  2 

1 . Smoothed  Data 

? 66  X 60  X 2.5  X 0.86  * 36 

Total  = 9.5  X 10®  words/readout 

2.  Fine  Data 

Total  = 39.9  X 10®  words/readout 
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The  requirements  that  are  associated  with  DMSP  and  TIROS-N  are: 


a.  Total  coverage  and  processing  of  smoothed  data  from  DMSP  and  TIROS-N 
(starting  in  1978),  and 

b.  Processing  of  three  percent  of  available  DMSP  fine  data  in  1978  and 
ten  percent  in  1980. 

The  maximum  data  input  will  occur  in  1980  when  AFGWC  is  processing  total  coverage 
from  the  DMSP  and  TIROS-N  smoothed  source  and  ten  percent  of  DMSP  fine  data.  Raw 
storage  is,  however,  constant  even  if  total  fine  data  processing  is  required  since 
we  assumed  three  percent  could  be  gathered  during  a single  orbit. 

a.  DMSP  Smoothed  Raw  Storage 


Vehicle  1 38  X 10°  words 

Vehicle  2 9.5  X 10^  words 

Total  47.5  X 106  words 

Two  dedicated  double-density  disk  units  (34M  words  each). 

DMSP  Fine  Raw  Storage 
1978 

39.9  X 106  words/readout  X 10  readouts  day  X 2 vehicles  X 0.03  (1978 
requirement).  Total  = 24  X 106  words.  One  dedicated  double-density 
disk  unit. 


39.9  X 10  words/readout  X 10  X 2 X 0.1  (1980  requirement).  Total  = 

80  X 10^  words  39.9  X 10^  words/vehicle  for  maximum  readout  per  vehicle. 
Note:  Allowing  for  75  percent  of  the  maximum  two-vehicle  readout  gives  a 
total  fine  raw  storage  of:  60  X 106  word/2  vehicles.  Two  dedicated 

double-density  disk  units.  This  much  raw  fine  storage  would  also  be 
sufficient  for  total  fine  data  processing.  The  75  percent  assumes  that 
total  real-time  conflict  will  not  occur  on  file  data  because  of  the 
selectivity  used  in  recording  specific  areas  of  high  interest. 
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TIROS-N 

Due  to  the  probability  of  real-time  readout  conflicts,  TIROS-N  will  require 
separate  storage  from  DMSP.  Storage  requirements  for  smoothed  data  will  be 
identical  to  DMSP.  No  requirements  exist  for  TIROS-N  fine  data  processing. 

GOES 

A single  GOES  readout  in  Mode  A requires  51  X 1 06  words  of  mass  storage  or 
two  dedicated  double- density  disk  units. 

TOTAL  ^MASS  STORAGE  COST  FOR  RAW  DATA 

The  total  number  of  double  density  disk  units  ($36,000  each  for  the  UNI VAC  I 
8433)  required  for  raw  data  input  is  eight  plus  a control  unit  ($100,000 
each).  Allocating  one  disk  controller  and  a pair  of  disks  for  backup  gives 
a total  price  of  $560,000. 

j 

DATA  COMPRESSION  COST 

— 

The  cost  associated  with  the  compression  of  raw  data  utilizing  a two-dimen- 
sional Fast  Fourier  Transformer  is  approximately  $0.5  for  each  2.66  mbs 
input  source  (hardware  only).  At  a minimum,  this  would  require  two  units 
plus  one  backup  to  process  the  smoothed  data  from  a single  vehicle  ($1.5M). 
Facilitating  multi  vehicle  support  within  and  between  TIROS-N  and  DMSP,  as 
well  as  handling  fine  and  smoothed  data  simultaneously,  would  further  in- 
crease the  cost.  Note:  This  cost  is  the  data  compression  only  and  does 

not  address  additional  costs  associated  with  data  reconstitution. 


SUMMARY/CONCLUSION 

I 

The  cost  for  storing  the  satellite  data  in  raw  form  on  double-density  disk  units 
(34M  words  each)  is  far  less  than  the  cost  associated  with  the  implementation  of 
data  compression.  The  cost  for  storage  in  raw  form  is  $560K  compared  to  several 
million  for  raw  data  compression.  Furthermore,  it  has  not  been  shown  at  this 
time  that  the  compression  parameters  can  significantly  enhance  other  functions 
(cloud  analysis). 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

113  - Special  Activities  - Program  D 
120  - Special  Activities  - ZOOM  Use 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 

A452-1  through  A452-5,  A114-1,  A515-4,  A313-12  through  A313-17,  A234-1  , 2, 
A441-1  through  A441-3,  A442-1 , A443-1 


TRADEOFF  TITLE 


AT 3-4  What  is  the  tradeoff  between  more  storage  area  and  data  packing  in  the 
meteorological  data  base  problem? 

REQUIREMENTS/BACKGROUND 

The  present  data  base  format  encourages  the  packing  within  a single  word  of  as 
much  data  base  information  as  is  possible.  The  primary  consideration  is  saving 
of  storage  area,  both  on  the  mass-storage  device  and  in  the  core  of  the  computer. 
But  as  more  storage  and  core  area  become  available  at  cheaper  prices,  computer 
time  spent  in  the  extra  packing  and  unpacking  may  be  more  significant. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  two  extremes  in  this  case  are  to  continue  to  encourage  packing  in  the  data 
base  or  to  prohibit  any  packing  of  data.  The  first  case  assumes  that  storage 
area  must  be  conserved  at  all  costs  and  the  second  one  uses  as  much  storage  as 
necessary  in  order  to  save  any  possible  compute  time. 

ANALYSIS 

The  primary  factors  which  reflect  on  this  situation  include: 

a.  More  mass  storage  available 

b.  More  and  faster  core  storage  available 

c.  More  preformatting  or  massaging  of  data. 

This  indicates  that  the  future  situation  will  be  more  complicated  than  the 
present  one  which  encourages  data  packing  to  save  mass  and  core  storage.  More 
core  and  mass  storage  and  faster  access  times  suggest  less  packing  is  necessary 
but  faster  core  says  that  packing  could  be  handled  more  effectively.  It  comes 

down  to  looking  at  each  individual  function  and  deciding  what  the  tradeoffs 
would  be. 

Prediction  models  like  ZOOM  and  AWSPE  could  lend  themselves  to  the  unpacked 
format  rather  well  since  the  grids  are  small  in  size  and  data  handling  is  not 
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a problem.  Functions  dealing  with  the  15  cloud  layers  per  grid  point  and  the 
very  dense  satellite  data  face  other  problems  since  it  would  take  massive 
amounts  of  additional  core  to  accommodate  them. 

If  the  data  are  preformatted  or  massaged  to  make  it  more  suitable  for  individual 
functions,  maybe  even  those  handling  cloud  and  satellite  information  can  be 
made  to  handle  it  in  an  unpacked  form.  The  question  is  not  a simple  one,  for 
each  function  there  needs  to  be  a tradeoff  between  computation  time  and  core 
with  a constraint  that  requirements  must  be  met. 

SUMMARY/CONCLUSION 

We  will  allow  independent  or  unique  pieces  of  data  to  be  stored  separately  and 
will  pack  data  which  is  closely  related  and  occurs  in  large  quantities.  This 
decision  reflects  the  complexity  of  the  hardware  situation  where  mass  storage 
will  be  available  at  cheaper  costs  and  computer  power  will  also  be  reduced  in 
price.  It  strikes  a median  between  these  two  costs. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 


All 5-1 , 2 
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TRADEOFF  TITLE 
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Al3-5  Should  discrete  satellite  data  storage  structure  be  used  for  analysis  and 
image  distribution  functions? 

i 


REQUIREMENTS/BACKGROUND 

Once  satellite  information  has  been  assimilated  into  the  GWC  data  system  it  has 
two  primary  use',:  analysis  algorithms  and  image  distribution  functions.  Because 
of  the  different  nature  of  these  two  applications,  there  may  be  a real  need  for 
unique  data  bases  to  exist. 


DESIGN  APPROACHES/CHARACTERISTICS 

The  present  approach  is  to  map  and  grid  all  satellite  data  to  a central  data 
base  in  both  polar  steographic  and  Mercator  projections.  Data  are  then 
extracted  from  this  storage  area  and  modified  (if  necessary)  for  the  specific 
application.  The  alternative  to  this  is  to  construct  two  types  of  software 
data  bases  designed  either  to  contain  information  for  analysis  models  or  for 
displays.  This  approach  would  allow  for  the  preprocessed,  prefiltered, 
or  otherwise  modified  data  to  be  stored  in  that  form  in  the  data  base,  already 
tailored  to  a specific  need. 


ANALYSIS 


The  redundant  storage  alternative  suggested  by  this  tradeoff  offers  the 

possibility  of  employing  two  techniques  which  may  be  advantageous  to  analysis 
functions: 


Satellite  data  preprocessing  before  data  base  storage  during  non- 
critical  time  periods, 

Satellite  data  statistical  reduction  by  hardware  before  data  base 
storage. 
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Many  satellite  data  will  be  ingested  and  analyzed  in  the  future  within  the 
sprint  sunstream  where  there  is  no  overhead  time  available  for  preprocessing; 
hence,  the  first  point  offers  no  advantage.  Data  reduction  by  hardware  is  not 
feasible  until  development  has  sJpowti  ways  that  the  reduced  parameters  can 
benefit  analysis  functions;  this  has  not  been  accomplished. 

Neither  the  requirements  which  would  justify  nor  the  advantages  derived  from 
the  separate  storage  of  satellite  data  to  be  used  for  analysis  or  display 
functions  have  been  identified. 

SUMMARY/CONCLUSION 

GWC  should  continue  with  its  present  plan  to  store  all  satellite  data  to  be 
used  by  both  display  and  analysis  functions  in  a single,  central  data  base 
until  such  time  as  another  direction  seems  advantageous. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

113  - Special  Activities  - Program  D 
120  - Special  Activities  - ZOOM  Use 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 

A115-1,  A241-6,  9,  A452-1  through  A452-5,  A515-1,  2,  4 
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TRADEOFF  TITLE 


A13-6  Should  WWMCCS  data  base  be  distinct  or  combined  with  general  data  bases? 
REQUIREMENTS/BACKGROUND 

To  satisfy  the  requirements  established  by  WWMCCS,  a data  base  different  from 
the  one  presently  at  GWC  will  be  required.  It  must  be  established  whether  this 
new  data  base  will  be  separate  and  distinct  or  combined  with  other  general 
data  bases. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  WWMCCS  data  base  can  be  designed  to  be  a unique  and  separate  area,  suitable 
for  WWMCCS  needs  only,  or  it  can  be  combined  with  a global  representation  of  all 
meteorological  parameters  of  interest  to  the  modernized  base  weather  station  as 
well  as  internal  GWC  forecasters.  The  second  suggestion  may  provide  a savings 
in  mass  storage  area  (by  cutting  down  on  some  redundancy),  but  it  will  pose  a 
significant  problem  involving  planning  and  integration  of  ideas. 


ANALYSIS 

We  think  the  concept  of  a WWMCCS  data  base  should  be  generalized  to  be  a user 
interface  data  base  which  includes  a global  representation  of  all  meteorological 
parameters  of  interest  to  the  modernized  base  weather  station,  WWMCCS  users,  as 
well  as  internal  GWC  forecasters.  The  structure  should  be  developed  hand-in-hand 
with  the  language  for  its  use.  It  should  also  involve  the  availability  of 
preformatted  human  user  or  machine  compatible  messages  for  presenting  the  data 
and  a hierarchical  request  structure  encompassing  the  time,  space,  and 
meteorological  parameter  vectors.  A User's  Guide  should  be  immediately  prepared 
with  updates  accommodating  user  requests  so  that  GWC  design  accommodates  rather 
than  is  dictated  by  user  requirements.  User  bulletins  should  be  issued  to 
increase  the  acceptability  and  usability,  and  user  agency  solicited  feedback 
should  provide  a basis  for  optimum  capability. 
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This  Trade  Study  is  related  to  the  following  requirements: 


200  - Command  and  Control  Systems  - All 

409  - Environmental  Support  - Operation  Security 

RELATED  SPECIFICATIONS 

A115-1  through  A115-3,  A131-1  through  A131-9,  A341-2,  4,  5,  7 
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TRADEOFF  TITLE 


A13-7  To  what  extent  should  application  programs  know  of  location  and  structure 
of  data? 

REQUIREMENTS/BACKGROUND 

In  the  process  of  retrieving  or  storing  data  in  a data  base,  it  may  enhance  the 
I/O  process  or  the  computations  done  by  the  applications  program  if  it  knows 
about  the  location  and  structure  of  the  data.  The  amount  of  prior  knowledge 
needed  by  the  applications  program  should  be  determined. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  two  extremes  include  giving  the  applications  program  no  knowledge  of  the 
location  and  structure  of  data  within  the  data  base  or  seeing  that  it  understands 
all  of  this  information.  The  first  approach  is  more  likely  to  mean  that  data 
base  changes  will  be  transparent  to  the  user  program  compared  to  the  second  case; 
but,  it  also  means  the  data  base  handler  will  necessarily  be  more  complicated. 

ANALYSIS 

There  are  many  changes  which  the  data  base  will  undergo  which  make  it  very 
undesirable  for  an  applications  program  to  expect  any  particular  location  and 
structure  for  data.  Some  of  the  primary  factors  producing  these  changes  include: 

a.  Gradual  expansion  of  the  data  base  due  to  storage  of  new  or  different 
parameters. 

b.  Use  of  "overlay"  data  bases  to  alleviate  security  problems. 

c.  Staging  techniques  for  storage  devices, 

d.  Preprocessing  or  reformatting  of  data  to  meet  specific  needs, 

e.  Use  of  filtering  of  data  in  place  of  memory  search. 


Among  other  complications,  these  new  procedures  and  the  fact  that  great  amounts 
of  mass  storage  will  be  available  far  cheaper  than  before  means  a large, 
redundant,  and  dynamic  data  base.  In  short,  it  would  be  a time-consuming 
procedure  for  an  applications  program  to  predict  the  location  and  structure  of 
the  data  it  needs.  To  meet  requirements  the  data  need  only  be  delivered  to  the 
function  in  the  proper  order  and  format  by  the  data  base  handler. 

SUMMARY /CONCLUSION 

No  knowledge  of  location  and  structure  of  data  within  the  data  base  is  needed 
by  applications  programs.  This  asserts  that  only  the  data  base  handler  need 
have  detailed  knowledge  of  the  exact  data  base  format. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 
A132-17,  18,  20,  21,  A332-1 
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TRADEOFF  TITLE 


A13-8  Should  a distributed  data  base  concept  be  allowed? 
REQUIREMENTS/BACKGROUND 

One  concept  of  data  base  design  involves  breaking  it  into  sections  which  relate 
to  their  functional  origins  or  usages  and  dedicating  the  storage  to  individual 
processors.  Three  divisions,  for  example,  might  be  associated  with  satellites, 
models,  and  conventional  observations.  This  "distributed"  data  base  concept  is 
an  option  opposed  to  the  central  data  base  theme. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  distributed  data  base  concept  is  in  conflict  with  the  central  data  base 
design  which  has  already  been  adopted  (see  A15-2  and  A15-9). 

ANALYSIS 

(See  A15-2  and  A15-9) 

SUMMARY/CONCLUSION 

There  will  be  a universal  data  base  with  classified  overlays.  Beyond  this  the 
exact  structure  is  yet  to  be  determined. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  releated  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 

A131-2,  3,  7,  8,  9,  A132-1,  4,  5,  9,  11,  12,  A261-1  (e,  k),  A341-3,  A251-1 


63 


TRADEOFF  TITLE 


A13-9  Will  the  present  meteorological  data  base  structure  accommodate  current 
requirements  and  what  are  the  alternatives? 


REQUIREMENTS/BACKGROUND 

The  present  meteorological  data  base  structure  at  GWC  is  the  product  of  an 
evolving  set  of  requirements.  The  result  is  that  it  may  now  resist  more  growth 
and  not  be  able  to  adjust  to  even  more  requirements.  Its  adaptability  to  change 
should  be  investigated. 


DESIGN  APPRA0CHES/CHARACTERIST1CS 

The  opposite  approaches  are  straightforward: 

a.  Keep  the  present  structure  for  the  meteorological  data  base. 

b.  Modify  the  meteorological  data  base  structure  so  that  it  can  more  easily 
accommodate  new  requirements. 


Cl 


ANALYSIS 

The  structure  of  the  data  base  is  based  on  three  vectors:  a time  vector,  a 
vector  in  which  each  element  is  a box- 3 space  and  a vector  which  has  each 
element  the  value  of  meteorological  parameter  in  that  space  at  the  time.  The 
present  data  base  structure  philosophy  accommodates  the  current  data,  but  will 
not  necessarily  accommodate  post-1977  versions.  Even  though  the  three  important 
vectors  remain  the  same  their  nature  changes. 

Starting  first  with  the  time  vector,  in  the  present  data  base  the  structure 
depends  to  some  degree  on  the  assumption  of  only  a few  convenient  intervals 
(older  data  are  purged).  It  assumes  purge  of  all  data  simultaneously  for  a 
given  time  and  point  in  3-space.  It  assumes  no  two  sets  of  data  can  be 
represented  at  a single  point  in  time.  With  the  existence  of  three  input 
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satellite  systems  updating  the  data  base  when  the  data  are  available  and  the 
possibility  for  purging  only  part  of  the  data  for  a given  point,  the  time 
dimension  takes  on  more  of  a continuous  nature  rather  than  being  discrete  and 
cycl ic. 

The  dimension  which  describes  a solid  in  3-space  also  is  changing  in  the 
era  of  the  new  architecture.  Presently  only  one  grid  scale  is  accommodated 
with  all  others  treated  as  an  exception.  With  the  mesoscale  support  of  tactical 
systems  sometimes  for  prespecified  target  areas,  it  seems  the  data  base  must 
accommodate  a variable  grid  structure  or  at  least  provide  an  equally  simple  and 
efficient  structure  for  each  system  as  well  as  a useful  interrelationship. 

We  envision  the  parameter  set  associated  with  a single-space  time  point  accommoda- 
ting more  variables,  but  on  the  other  hand  allowing  a wider  variation  in  the 
number  of  variables  represented  at  a single  point.  This  may  be  due  to  the  need 
for  identification  of  data  source  and  data  reliability.  Observation  is  needed 
in  the  probabilistic  line  of  sight  problem,  for  example.  We  see  the  expansion 
of  trend  variables  or  trend  statistics  as  possible  parameters.  The  new  structure 
must  accommodate  an  expansion,  even  though  we  cannot  currently  identify  exactly 
what  that  expansion  will  be. 


There  are  cascading  effects  associated  with  the  changes  mentioned  above.  For 
example,  we  can  no  longer  necessarily  afford  to  automatically  duplicate  the 
meteorological  data  base  on  all  systems  if  the  time  update  is  on  an  almost 
continuous  scale.  The  structure  of  the  system  may  be  so  complex  in  storage  that 
both  users  and  user  programs  must  have  a simpler  visualization  of  the  structure 
than  that  actually  incorporated.  Thus,  data  base  management  routines  and  an 
"apparent  structure"  must  be  developed. 
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If  we  are  unable  to  update  d<tta  bases,  a new  security  problem  is  imposed  if  all 
systems  are  to  work  off  of  a single  data  base.  A potential  solution  is  the  use 
of  overlap  data  bases  which  are  classified  and  contained  within  a secure 
environment  as  well  as  a concept  of  requesting  data  from  a higher  to  a lower 
level . 


The  final  consideration  involves  the  availability  of  different  hardware  capabili- 
ties in  the  1982  era.  Manufacturers  have  incorporated  staging  techniques  which 
allow  data  to  be  moved  from  slower  to  more  rapid  access  devices  (e.g.,  from  tape 
to  disk  to  auxiliary  memory  to  main  memory).  Further  we  can  buy  great  amounts  of 
mass  storage  much  cheaper  than  we  ever  could  before  thus  allowing  more  efficiency 
in  addressing  and  access  at  the  cost  of  a little  more  wasted  memory. 

The  additional  storage  and  the  availability  of  fast-array  processors  suggest  pre- 
processing into  applications-peculiar  formats.  It  suggests  redundancy  for  overlap 
storage  to  ensure  rapid  sequential  read  for  contiguous  areas.  It  may  even  imply 
sequential  read  and  filter  as  opposed  to  memory  search. 

SUMMARY/CONCLUSION 

It  is  SDC's  opinion  that  simply  modifying  the  current  data  base  structure  is  an 
undesireable  approach  in  formulating  the  new  meterological  data  base.  We  think 
that  a hierarchical  gridding  system  (such  as  the  Navy's  spherical  triangle 
system)  should  be  investigated  and  recommended.  The  data  base  structure  should 
then  be  optimized  to  fit  the  application. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


AT 3-10  What  Dreformatting  of  data  can  be  accomplished  during  nonresource 
critical  periods  to  accommodate  faster  processing  at  run  time? 


REQUIREMENTS/BACKGROUND 

Before  a model  or  other  function  can  make  use  of  information  stored  in  the  data 
base,  it  is  often  necessary  to  preprocess  or  massage  the  data,  putting  it  in  a 
form  more  adaptable  to  the  specific  use.  If  this  preformatting  can  be  accomp- 
lished prior  to  the  function's  execution,  then  run  time  may  be  reduced  during 
resource  critical  periods. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  present  mode  is  to  store  a single  representation  of  all  data  in  their  simplest 
form  in  the  data  base.  Any  modifications  to  the  data  base  (no  matter  how  simple 
or  complex)  are  then  left  to  the  user  program  to  perform.  The  opposite  approach 
would  consist  of  storing  all  data  in  the  data  base  in  the  form  that  they  will  be 
used  in  (whether  preformatted,  filtered,  or  otherwise). 

ANALYSIS 

At  times  it  is  possible  to  represent  the  same  quantity  in  several  different  ways 
for  different  needs.  A trivial  meteorological  example  would  be  to  list  tempera- 
ture as  either  Kelvin,  Centigrade,  or  Fahrenheit. 

If  these  simple  conversions  could  be  made  before  the  models  ran  which  used  them, 
we  could  save  some  computation  time  when  it  is  needed  most.  The  probable  avail- 
ability of  adequate  mass  storage  now  makes  preformatting  even  more  feasible. 

One  obvious  place  where  preformatting  shows  promise  involves  the  handling  of 
observational  data.  They  are  primarily  used  as  input  to  the  analysis  routines 
and  they  may  consist  of  up  to  120  parameters  packed  in  30  words.  Decoding  this 
for  some  particular  information  can  be  a big  job  for  an  analysis  routine  and 
maybe  one  that  can  be  done  prior  to  its  execution. 
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Analyzing  satellite  data  for  cloud  information  is  a tedious  procedure  (due  to 
the  large  data  amounts)  and  most  of  it  might  also  be  done  earlier-preprocessed 
and  preformatted  for  use  by  the  cloud  analysis  routines. 


An  example  of  the  potential  gain  due  to  preformatting  concerns  the  conversion 
between  the  grid  that  the  AWSPE  works  in  (53  x 57),  and  the  data  base  grid 
(47  x 51).  (The  large  area  is  necessary  to  minimize  boundary  instability 
problems.)  The  smaller  grid  is  a point-for-point  subset  of  the  larger,  but 
still  the  conversion  between  grids  takes  about  10  minutes  SUPS  per  execution 
of  the  AWSPE.  At  the  present  time  the  AWSPE  is  scheduled  to  closely 
follow  the  execution  of  the  analysis  routines  so  that  no  overhead  time  is 
available  for  preprocessing.  Future  systems  however,  with  faster  computation 
rates  and  data  base  handling  routines  adept  at  data  formatting,  make  such 
preprocessing  of  data  more  feasible  and  attractive,  benefitting  routines  like 
the  AWSPE. 

SUMMARY/CONCLUSION 

Preformat  data  for  specific  uses  when  it  is  cost  effective  to  do  so,  storing 
both  the  initial  and  pr,eformatted  representations  in  the  data  base. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

200  - Command  and  Control  Systems  - All 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

RELATED  SPECIFICATIONS 
A1 32-22 
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TRADEOFF  TITLE 


A13-11  What  generalized  data  structuring  is  warranted  (e.g. 
output  messages)? 


communications 


REQUIREMENTS/BACKGROUND 

The  factors  which  warrant  generalized  data  structuring,  for  example  in  communi- 
cations output  messages,  must  be  established. 


DESIGN  APPROACHES/CHARACTERISTICS 
(See  ANALYSIS) 


ANALYSIS 


There  are  two  principal  reasons  for  generalization:  a)  to  enhance  recogniz- 

ability  of  messages  for  security  checking;  b)  to  simplify  the  human  interface, 
thereby  reducing  the  chance  for  human  error  and  simplifying  the  training  for 
human  interface.  Other  reasons,  though  not  as  important,  are  simplifying  the 
programming  task  for  software  development  and  documenting  easy-to-understand 
standards  as  a means  for  interface  definition  control.  Based  on  these  reasons, 
the  primary  candidates  are  input  and  output  communications  messages,  all  human 
interface  messages  and  input  formats,  and  the  definitions  of  programmer  inter- 
faces with  modules  and  data  structure.  All  interfaces  between  components  are 
candidates  as  well  as  interfaces  between  distinct  functional  areas  (e.g., 
satellite  data  processing,  communications,  network  control). 


SUMMARY/CONCLUSION 

Reasons  for  generalizing  data  structure: 
a.  Simplicity  for  security  checking 
Simplicity  for  reducing  human  error 
Simplifying  programming 
Easier  documentation 


b. 

c. 

d. 


69 


\ 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

115  - Special  Activities  - Agency  B 
200  - Command  Control  Systems  - All 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

RELATED  SPECIFICATIONS 
A1 32-21,  A461-1 
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TRADEOFF  TITLE 


A13-12  What  are  the  data  base  complications  in  using  an  associative  processor 
for  data  management? 

REQU I REMENTS/BACKGROUND 

The  complex  job  of  data  base  management  may  be  adaptable  to  an  associative 
processor.  The  possibilities  and  complications  of  this  should  be  studied. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  possible  approaches  to  a data  base  management  processor  include  either  a 
conventional  processor  or  an  associative  processor  assisting  its  host. 


ANALYSIS 

Data  base  management  as  it  is  currently  known  is  an  I/O-bound  function.  The 
operations  performed  on  the  data  take  far  less  time  than  the  ability  to  search 
and  read  the  data.  If  we  expand  the  definition  of  data  base  management  to 
include  the  application-specific  process  of  optimum  formatting,  enhancing  the 
capability  for  search-by- value  becomes  even  more  key. 

The  natural  inclination  is  that  an  associative  processor  would  not  efficiently 
do  the  total  data  base  management  job,  but  the  associative  processor  along  with 
a host  might. 


There  are  some  scheduling  implications  resulting  from  the  use  of  the  associative 
processor  for  the  data  base  management  function.  The  number  of  associative 
processors  in  option  E of  table  10.11  is  based  on  our  estimate  of  worst-case 
conflict  between  the  five  major  models.  If  data  base  preprocessing  were  linked 
to  the  running  of  another  time-critical  application  program,  we  would  have  to 
avoid  the  conflict.  Therefore,  the  associative  processor  and  its  backup  must 
be  dedicated  to  the  task  of  assisting  the  data  base  manager. 


The  hardware  cost  of  this  approach  is  approximately  $1.5  million.  This  large 
sum  must  be  weighed  against  the  ability  of  the  associative  processor  to  decrease 
response  time  in  the  network  (faster  preformatting  and  search)  and  to  offload  its 
host.  In  addition,  the  associative  processor's  search  capabilities  allow  far 
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greater  freedom  of  data  base  struc  re,  which  will  be  very  important  in  trying 
to  meet  user  (e.g.,  WWMCCS)  response -time  criteria.  This  flexibility  is  also  key 
to  assimilating  the  multitude  of  satellite  sensor  data  Into  a central  data  base, 
because  of  the  varying  grid  sizes  between  sensors  and  the  nonuniform  time  space- 
ing  between  samples  of  the  atmosphere. 

SDC  does  not  feel,  however,  that  the  $1.5  million  hardware  cost  can  be  quantita- 
tively justified  at  this  point  in  time.  The  use  of  an  associative  processor 
should  be  reviewed  as  requirements  harden  and  as  the  future  data  base  structure 
becomes  more  well  defined. 

SUMMARY/CONCLUSION 

An  associative  processor  is  not  cost-justifiable  at  this  time  for  the  data  base 
management  job.  Therefore,  a conventional  processor  will  be  used  without  asso- 
ciative processor  assistance. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 
None 
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AT 3-1 3 Is  there  an  application  for  a Data  Management  System  produced  by  a 
vendor  (especially  consider  UNIVAC  1100  DMS)? 

REQUIREMENTS/BACKGROUND 

The  Data  Management  System  (DMS)  in  use  at  GWC  is  the  result  of  in-house  develop 
ment  but  may  lack  the  sophistication  to  adapt  to  radical  data  base  changes.  The 
possibility  of  using  a vendor-produced  DMS  in  this  area  should  be  investigated. 

DESIGN  APPROACHES/CHARACTERISTICS 
(See  ANALYSIS) 

ANALYSIS 

Vendor-produced  data  management  system  packages  are  oriented  towards  commercial 
applications.  That  is,  vendor  DMS  packages  are  targeted  for  the  efficient  pro- 
cessing of  extremely  large  data  bases  for  applications  which  have  low  transac- 
tion rates.  DMS  packages  provide  capabilities  to  design  and  structure  a data 
base  and  capabilities  to  access  data  from  such  a data  base.  Data  accessing 
statements  are,  or  can  be,  relatively  independent  of  Higher  Order  Languages 
(HOL)  which  are  used  to  code  the  programs  which  use  this  data.  However,  current 
vendor  implementations  require  a host  HOL,  usually  COBOL.  Such  is  the  case  with 
the  UNIVAC  1100  DMS.  Additionally,  protection  from  unauthorized  access  to  data 
or  changing  of  data,  if  provided,  is  oriented  for  commercial  applications.  The 
vendor-provided  DMS  provides  high  transaction  rates  combined  with  constant 
demand  and  military  security. 

Design  decisions  which  have  been  made  and  design  options  which  require  further 
study  indicate  that  the  utility  of  any  vendor-supplied  DMS  package  would  be 
severely  limited.  A single  universal  unclassified  data  base  with  classified 
overlays  where  the  storage  and  processing  options  for  the  universal  data  base 
include  retrieval  from  mass-memory  storage  facilities  or  disk  by  an  associative 
processor,  one-way  data  paths  for  security,  and  assignment  of  jobs  to  specific 
processors  and  their  associated  data  base  files  to  the  specific  processor  disk 
by  Network  Control,  limit  the  utility  of  a vendor-supplied  DMS  to  effecting  the 
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data  management  interface  between  the  application  programs  operating  on  the 
processor(s)  selected  by  Network  Control  and  the  disk(s)  attached  to  the 
selected  processor (s) . The  possibility  of  multiple  hardware  vendors  could 
further  limit  the  utility  of  a vendor- produced  DMS  package  in  that  it  could 
reduce  the  number  of  processors  on  which  the  DMS  package  could  be  used.  A 
major  portion  of  the  Data  Management  System  required  for  AFGWC  is  retrieval 
from  (or  restoration  to)  the  centralized  data  base  unclassified  files  required 
or  processed  by  applications  programs  and  any  associated  classified  overlays. 
Development  of  software  to  effect  such  an  interface  between  the  data  base  and 
a switching  and  routine  system  with  stringent  security  features  and  Network 
Control  must  be  done  for  AFGWC. 

The  UNIVAC  1100  Data  Management  System  received  special  consideration  in  that 
some  tradeoff  comparisons  between  UNIVAC  1100  DMS  and  the  Data  Management  Sys- 
tem currently  in  use  at  AFGWC  were  attempted.  Some  of  the  advantages  which  the 
UNIVAC  DMS  provides  include:  vendor  maintenance  of  the  data  management  system; 

a separate  data  base  design  or  structuring  language,  the  Data  Definition  Lan- 


guage (DDL);  provision  for  a variety  of  search  structures;  central  control  of  , 

all  access  to  the  data  base  through  the  Data  Management  Routine  (DMR) , and 
rollback  and  recovery  capabilities  for  restoration  of  the  data  base  after  loss 
of  integrity.  However,  UNIVAC  1100  DMS  is  a general-purpose  DMS  targeted  for 
commercial  users  as  opposed  to  the  data  management  system  developed  at  GWC, 
which  is  tailored  for  current  GWC  requirements  and  which  should  be  more  respon- 
sive to  GWC  future  needs.  One  additional  point  which  applies  to  all  vendor 
packages,  not  just  UNIVAC  1100  DMS,  is  relevant.  Namely,  that  vendor  scheduling 
for  fixing  of  errors  or  updating  the  DMS  to  reflect  changes  in  the  Operating 
System  or  changes  in  the  data  base  itself  cannot  be  as  responsive  as  can  be  pro- 
vided by  GWC  personnel. 

At  this  point  in  the  GWC  study,  no  compelling  reasons  are  evident  which  would 
cause  GWC  to  deviate  from  the  use  of  FORTRAN  for  development  of  GWC  applications 
programs.  Many  reasons  continue  to  encourage  the  use  of  FORTRAN  as  the  standard 
basic  language  for  development  of  GWC  applications.  Continued  use  of  FORTRAN 
should  minimize  software  breakage  in  that  programs  currently  written  in  FORTRAN 
which  continue  to  be  valid  can  be  transferred  to  new  computers  and/or  new  opera- 
ting systems  at  less  cost  than  programs  developed  in  other  languages.  New  pro- 
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grams  developed  in  FORTRAN  will  be  more  portable  than  programs  developed  in 
other  languages  in  that  they  can  be  transferred  to  new  computers  in  the  post- 
1982  period.  With  continued  use  of  FORTRAN  as  the  basic  software  development 
language,  training  costs  can  be  contained  in  that  less  training  will  be  required 
and  better  training  at  lower  cost  has  evolved  with  the  continued  use  of  FORTRAN. 
FORTRAN  compilers  provide  for  generating  highly  efficient  object  code  for  arith- 
metic, relational,  and  control  statements.  Additionally,  continued  use  of  FOR- 
TRAN provides  more  leeway  in  hardware  considerations  in  that  FORTRAN  compilers 
have  been  developed,  or  are  under  development,  for  the  array  processors. 

Assuming  FORTRAN  will  continue  as  the  basic  GWC  language  for  development  of 
applications  programs  and  assuming  that  the  previous  discussion  doesn't  preclude 
a COBOL-hosted  DMS  such  as  UNIVAC  1100  DMS  from  further  consideration,  the  next 
thing  to  investigate  is  how  much  software  (FORTRAN  applications  and  COBOL-hosted 
DMS)  would  interface.  In  order  to  avoid  confusion  factors  in  such  an  investiga- 
tion, the  desirability  of  having  a centralized  run-time  Data  Management  Routine 
which  controls  all  access  to  the  data  base  and  the  desirability  of  having  this 
run-time  DMS  interface  with  a description  of  the  pertinent  data  base  components 
(schema)  is  taken  for  granted.  Options  for  effecting  such  an  interface  include: 

a.  Writing  a series  of  small  COBOL  programs  which  contain  the  Data  Mani- 
pulation Language  (DML)  statements  required  for  the  data  base  access 
and  writing  the  calls  to  the  COBOL  programs  in  the  FORTRAN  applica- 
tions programs  (much  as  the  calls  to  access  data  now  a;. pear).  The 
variations  of  possible  combinations  of  DML  argument.'  and  statements 
are  numerous,  and  the  variety  of  ways  an  applications  programmer  might 
use  to  assemble  the  necessary  data  is  also  numerous.  The  possibili- 
ties range  from  an  overwhelming  number  of  COBOL  programs  and  even 
more  subroutine  calls  from  FORTRAN  programs  to  a few  COBOL  programs 
oriented  towards  DML  logical  subcategories  (or  possibly  oriented 
towards  specific  portions  of  the  data  base)  with  multiple  entry  points 
and  long  parameter  (argument)  lists.  Although  the  subroutine  call- 
subroutine  entrance-subroutine  exit  linkages  between  COBOL  programs 
calling  COBOL  subprograms  are  the  same  as  the  linkage  between  FORTRAN 
programs  calling  FORTRAN  subprograms,  this  approach  might  cause  some 
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problems  in  that  both  FORTRAN  and  COBOL  expect  the  MAIN  program  to 
be  written  in  their  respective  languages. 

b.  Writing  one  COBOL  program  for  a given  processor-disk  configuration 
which  implements  all  data  base  interface  processing  using  DML  state- 
ments and  transfers  control  to  the  FORTRAN  applications  program  which 
is  coded  as  a FORTRAN  subroutine.  In  effect,  the  COBOL  main  program 
would  function  as  the  data  base  interface  and  the  scheduler  or  control 
program.  This  approach  seems  more  straightforward  from  a data  manage- 
ment point  of  view.  However,  the  impact  of  changing  all  the  FORTRAN 
programs  to  subroutines  called  from  a COBOL  main  program,  and  the 
likelihood  that  a scheduling  program  written  in  COBOL  would  be  too 
inefficient, detract  from  any  appeal  that  this  approach  might  have.  A 
more  important  consideration  is  whether  or  not  the  AFGWC  data  process- 
ing jobs  would  function  well  within  such  a structure. 

c.  Another  possibility  suggested  for  interfacing  FORTRAN  applications 
programs  with  a COBOL-hosted  data  management  system  calls  for  the 
writing  of  a COBOL  program  with  DML  statements  in  it  which  reflect  the 
type  of  DML  action  required  by  FORTRAN  applications  programs.  Since 
DML  statements  are  transformed  by  the  DML  preprocessor  into  calls  to 
the  Data  Management  Routine  (DMR) , the  applications  programmer  could 
hand-copy  the  DMR  subroutine  calls  into  the  appropriate  place  in  the 
FORTRAN  application  program.  In  addition  to  programming  manpower 
inefficiently  applied  to  copying  the  calls,  the  debugging  of  programs 
constructed  in  such  a way  is  far  from  easy. 

The  approaches  described  above  for  interfacing  FORTRAN  applications  programs  with 
COBOL-hosted  Data  Manipulation  Statements  all  appear  cumbersome  and  time-consuming 
from  a program  development  point  of  view.  They  create  an  extra,  unnecessary 
run-time  linkage  overhead  not  existent  in  the  current  system  and  not  required 
for  a FORTRAN-hosted  Data  Management  System,  and  provide  no  improvement  over 
the  current  system. 

Since  data  bases  and  the  structures  of  data  bases  are  subject  to  change,  the 
interface  of  FORTRAN  applications  programs  with  COBOL-hosted  data  base  manage- 
ment systems  creates  an  ongoing  problem  for  programming  personnel  and  an  ongoing 
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source  for  software  reliability  programs.  The  problem  naturally  arises  because 
COBOL  host  DMS  systems  are  not  intended  for  interface  with  FORTRAN  programs. 

When  changes  to  the  data  base  or  the  data  base  structure  are  made,  a self- 
contained  COBOL  application  and  DMS  system  merely  needs  recompilation  to  ensure 
that  the  proper  structures  exist  for  receipt  of  the  data  by  the  applications 
program.  Such  would  not  be  the  case  for  a FORTRAN  program.  Each  time  a data 
hase  change  and  corresponding  COBOL  recompilation  occurred,  manual  changes 
might  be  required  for  the  FORTRAN  program  with  a requirement  for  program  testing 
each  time  a change  was  made. 

The  nature  of  the  AFGWC  data  processing  job,  the  desirability  of  continued  use 
of  FORTRAN  for  applications  programs,  and  the  design  decision  for  a single  uni- 
versal data  base  with  classified  overlays  all  dictate  that  a special-purpose 
Data  Management  System  with  characteristics  which  reflect  AFGWC  requirements 
and  priorities  be  developed  for  AFGWC. 

SUMMARY/CONCLUSIONS 

A vendor-produced  data  management  system  will  not  fit  AFGWC  requirements.  The 
UNIVAC  1100  DMS  requires  COBOL  as  the  host  language  and  would  degrade  process- 
ing even  more  than  a vendor-produced  data  management  system  which  provides  for 
FORTRAN  as  the  host  language. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 

A13-14  Is  there  a need  to  record  access  and  usage  statistics? 
REQUIREMENTS/BACKGROUND 

Data  base  access  and  usage  statistics  may  be  a valuable  input  allowing  GWC  to  do 
internal  tradeoff  studies  which  would  determine  when  fields/models  have  outlived 
their  usefulness.  Presently  these  statistics  are  not  available  in  an  automated 
rrr*^" 

DESIGN  APPROACHES/CHARACTERISTICS 

In  the  present  mode  no  data  base  statistics  are  collected.  The  alternative  to 
this  is  to  provide  the  ability  to  collect  necessary  data  base  usage  statistics 
for  internal  tradeoff  studies.  This  becomes  even  more  feasible  with  the  design 
decision  having  been  made  to  have  a centralized  data  base  with  classified  over- 
lays. This  simplifies  the  bookkeeping  problem. 

ANALYSIS 

Collecting  data  base  usage  statistics  has  been  a goal  long  sought  after  by  GWC. 
Increased  run  time  and  other  operational  problems  has  made  this  collection  impos 
sible  in  the  past  but  it  will  be  part  of  the  reentrant  data  base  handler  package 
being  developed  now.  The  need  for  these  statistics  arises  from  the  fact  that 
the  demand  for  certain  portions  of  GWC's  data  base  varies  with  time.  If  a need 
disappears  or  is  sufficiently  low,  the  data  base  and  model  that  built  it  may  be 
candidates  for  deletion.  This  would  save  not  only  mass  storage  but  possibly 
computation  time.  The  present  method  of  making  this  determination  is  manual, 
time-consuming,  and  far  from  exact. 

SUMMARY/CONCLUSION 

The  ability  to  collect  necessary  data  base  usage  statistics  for  internal  trade- 
off studies  should  be  provided. 
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TRADEOFF  TITLE 


A13-15  What  are  the  tradeoffs  between  a demand  versus  service  versus  update 
interface  with  the  central  unclassified  data  base? 

REQUIREMENTS/BACKGROUND 

The  question  is  whether  the  central  data  base  manager  should: 

a)  send  data  only  on  request, 

b)  broadcast  changes  to  the  data  base  when  these  reach  a 
certain  level  of  significance,  or 

c)  periodically  broadcast  updates. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  two  opposing  points  of  view  are  summed  up  by  these  statements: 

a.  Only  the  simplest  of  read/write  access  capabilities  of  the  unclassi- 
fied data  base  are  required  by  the  average  user. 

b.  The  master  data  base  management  capability  shall  afford  a variety  of 
options,  including: 

1)  obtain  data  by  location 

2)  obtain  data  by  value 

3)  search  upon  update  based  on  thresholds 

4)  initiate  action  based  on  update 

ANALYSIS 

We  think  that  the  interface  with  the  general  unclassified  data  base  need  not  be 
restricted.  However,  we  encourage  strict  control  over  this  freedom.  The  prin- 
cipal usage  of  the  base  should  be  one  of  requesting  data  when  they  are  needed 
to  ensure  up-to-date  information  and  a minimum  of  interaction  with  the  data 
base  manager.  In  cases  where  the  data  base  must  be  monitored  to  search  for 
threshold  violations  or  increments  in  parameter  values,  the  data  base  manager 
should  accomplish  these  requests  by  notifying  the  network  controller  of  needs 
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to  activate  certain  capabilities.  It' may  also  necessitate  updating  certain 
classified  data  bases;  however,  no  such  examples  of  this  action  can  currently 
be  identified.  It  is  important  to  develop  a master  data  base  users'  language 
and  a set  of  options  which  can  be  available  for  use  by  the  individual  routines 
of  the  system.  We  believe  that  response  afforded  by  a master  data  base  manage- 
ment subsystem  as  well  as  the  transfer  of  high-speed  data  will  accommodate  any 
user's  timing  requirements  (e.g.,  in  the  case  of  the  advanced  prediction  model, 
preprocessing  can  set  up  vector  forms  and  auxiliary  memory  to  facilitate  rap, id, 
handling  by  array  type  processors). 

Updating  in  the  master  data  base  requires  design  emphasis.  We  suggest  updating? 
portions  of  the  data  base  while  having  previous  counterparts  available  for 
simultaneous  requests.  Upon  completion  of  the  update  of  a smaU  portion  this 
will  be  made  to  supersede  its  predecessor  data.  The  data  base  management  rou- 
tine will  always  know  what  it  should  fr-eat  as  current  and  will  respond  to 
requests  accordingly. 

SUMMARY/CONCLUSION 

The  master  data  base  management  capability  shall  afford  a variety  of  options, 
including: 

(1)  obtain  data  by  location 

(2)  obtain  data  by  value 

(3)  search  upon  update  based  on  thresholds 

(4)  initiate  action  based  on  update 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 


RELATED  SPECIFICATIONS 


A132-17 
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TRADEOFF  TITLE 

AT 3-1 6 Is  a data-oriented  language  warranted  for  use  at  AFGWC?  If  so,  what 
should  be  the  nature  of  the  language? 

REQUIREMENTS/BACKGROUND 

The  primary  applications  computer  language  used  at  GWC  is  FORTRAN.  :t  has 
obvious  shortcomings  when  it  comes  to  data  transfer  and  handling.  It  may  be 
possible  to  augment  or  replace  FORTRAN  where  these  processes  are  concerned. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  following  approaches  have  been  considered  in  this  study: 

a.  Use  FORTRAN  exclusively  even  where  datu  handling  is  concerned. 

b.  Replace  FORTRAN  by  a data-oriented  language  (like  C0MP00L  specifi- 
cation statements)  where  data  handling  is  concerned. 

c.  Replace  FORTRAN  entirely  with  a language  (like  APL)  which  provides 
adequate  capabilities  for  data  handling  and  computation. 

d.  Augment  FORTRAN  with  a language  that  would  complement  its  data- 
handling  deficiencies. 

ANALYSIS 

Data  management  statements  which  explicitly  represent  the  data  management  actions 
desired  by  the  data  base  user  provide  for  easy  use,  easy  understanding,  and  easy 
modification.  This  improvement  over  the  present  data  base  access  method  derives 
from  the  explicit  form  of  the  data  manipulation  statements  in  that  the  user  de- 
fines in  such  a statement  exactly  what  he  wants  done  with  a specific  set  of  data 
(rather  than  setting  up  a subroutine  call  to  a data  management  routine  where  the 
data  reference  is  implicit  and  must  be  constructed  using  documentation  describ- 
ing the  call  and  the  parameters).  These  program  development  advantages  become 
system  advantages  which  facilitate  standardization  and  management  control  of 
both  the  data  base  and  programs  which  access  the  data  base  in  an  environment 
such  as  GWC  where  there  is  an  ongoing  requirement  for  the  data  base,  a require- 
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ment  for  modification  of  programs  which  use  this  data  base,  an  imnediate 
requirement  for  the  development  of  additional  applications  programs  which 
access  the  data  base,  and  a high  probability  for  long-range  development  of 
additional  programs  which  utilize  the  6WC  data  base. 

Data-declaration  statements  oriented  for  design  and  construction  of  the  data 
base  provide  for  improved  data  processing  in  a manner  similar  to  the  data  mani- 
pulation statements  discussed  previously.  The  data  base  controller  or  the 
data  base  design  maintenance  group  are  provided  with  tools  (data  base  design 
declaration  statements)  which  facilitate  the  definition  and  construction  of  a 
data  base  specific  to  the  needs  of  the  system  of  data  base  users. 

Continued  use  of  FORTRAN  for  development  of  AFGWC  applications  .programs  is 
probable  and  desirable.  Such  use  will  minimize  reprogramming  of  current  appli- 
cations software,  given  that  most  of  the  current  programs  are  written  in  FOR- 
TRAN, and  increase  the  transferability  of  future  applications  software. 

The  design  decision  (see  A16-3)  that  the  GWC  data  base  management  system  be 
developed  at  GWC  and  the  conclusion  hat  FORTRAN  will  continue  to  dominate  as 
the  language  for  applications  software  dictate  the  development  of  support  soft- 
ware to  process  data-oriented  statements  assuming  a tradeoff  conclusion  that  a 
data-oriented  language  is  warranted  for  use  at  AFGWC  and  further  assuming  an 
AFGWC  commitment  to  implement  such  a language.  The  structure  and  capability 
requirements  of  such  support  software  therefore  becomes  relevant  to  this  trade- 
off analysis. 

Independent  of  decisions  regarding  retention  of  the  current  system,  a require- 
ment would  exist  for  a processor  (or  processors)  that  is  capable  of  receiving 
mixed  Data  Management  Languat  (DML)  and  FORTRAN  source  statements  whic*-. 
a)  describe  (for  design  or  construction)  the  data  base,  or  b)  constitute  a 
FORTRAN  application  program  with  a capability  to  refer  to  data  base  data 
using  DML  statements.  Representative  processors  capable  of  making  such  trans- 
formations include:  a)  a preprocessor  developed  by  General  Research  Corporation 
ENLODE,  which  combines  some  elements  of  a higher-order  language  suited  for 
specifying  Ballistic  Missile  Defense  (BMD)  engagement  logic  with  elements  of  a 
higher  order,  data  oriented  language  suited  for  translation  to  FORTRAN  source 
code  which  effects  the  interface  with  a centralized  BMD  data  base;  and  b)  the 
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UNIVAC  1100  DMS  preprocessor  which  accepts  combined  Data  Manipulation  Language 
(DML)  and  COBOL  source  statements  and  produces  (COBOL  source  statements  which 
include  subroutine  calls  to  the  Data  Management  Routine  (DMR)  in  order  to 
implement  the  action  of  the  DML  statement.  Such  preprocessors  are  not  overly 
complicated,  and  development  of  like  processors  can  be  accomplished  using 
standard  compiler  development  context  analysis,  syntax  driven,  or  macro 
processing  techniques. 

Development  of  such  a preprocessor  using  macro  processing  techniques  is  espe- 
cially attractive  in  that  in  addition  to  implementing  the  desired  data  manage- 
ment extension  to  FORTRAN,  it  provides  an  ongoing  capability  to  supplement 
FORTRAN  through  the  use  of  MACRO  declarations  and  MACRO  calls.  Such  a capability 
could  be  used  to  add  new  data  management  capabilities  to  the  baseline  data  manage- 
ment language,  provide  AFGWC  language  extensions  to  FORTRAN  which  would  be  con- 
sistent with  structured  programming  (e.g.,  IF-THEN-ELSE,  DO  WHILE,  and  CASE  Mac- 
ros), or  to  develop  Higher  Order  Language  constructs  suitable  for  the  analysis, 
development,  and/or  construction  of  GWC  systems.  An  operational  example  of  this 
type  of  processor  is  the  SDC-developed  AMPLE  (an  Adaptable  Macro  Processor  for 
Language  Extensions)  which  processes  MACRO  declarations  written  in  FORTRAN,  re- 
trieves canned  FORTRAN  Macros  from  a Macro  library  and  translates  programs  con- 
taining AMPLE  MACRO  calls  into  FORTRAN  source  programs.  A macro  processor  of 
this  type  could  be  used  for  developing  experimental  language  forms  suitable  for 
consideration  as  Higher  Order  Language  forms  tailored  to  GWC  processing  needs. 

A baseline  specification  suitable  for  use  in  developing  a data-oriented  language 
for  AFGWC  is  available.  The  CODASYL  data  base  task  group  has  produced  specifica- 
tions for  a data-definition  language  which  should  be  an  industry  standard  and 
specifications  for  a data  manipulation  language  (which  augments  COBOL)  which  can 
serve  for  guidance  in  the  development  of  a data  manipulation  language  to  augment 
FORTRAN.  The  CODASYL  data  base  task  group  recommendations  for  a data-oriented 
language  are  the  result  of  a long  and  concerted  effort  by  leaders  in  data  manage- 
ment techniques.  Their  specification  represents  the  best  in  current  thinking  on 
language  forms  relevant  to  present-day  hardware. 
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SUMMARY/CONCLUSIONS 


A data-oriented  language  is  warranted  for  use  at  AFGWC.  This  language  should 
augment  FORTRAN  for  data  handling  and  should  provide  tools  for  data  base  con- 
struction. The  CODASYL  data  base  task  group  language  specifications  are  recom- 
mended for  use  as  a baseline  specification. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 
A332-1 
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TRADEOFF  TITLE 

A20-1  How  does  intercommunication  take  place  within  the  GWC  architecture? 
REQUIREMENTS/BACKGROUND 

The  requirements  for  intercommunication  are  driven  by  three  basic  things: 

a.  the  security  requirements  for  control-only  data  flow,  one-way  data  flow, 
and  authentication  coded  data  paths  within  the  system; 

b.  Processor  flexibility  to  commonly  seek  data  from  a variety  of  data 
bases  thereby  increasing  the  alternatives  in  resource  allocation;  and 

c.  satisfaction  of  contractor  maximum  distance  criteria  for  component 
connection. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  design  approaches  are  obvious  if  we  are  to  meet  the  requirements.  There 
must  be  rapid  switching  on  the  order  of  seconds  from  one  security  level  to 
another,  these  must  be  a way  of  communicating  control  information  from  a 
higher  security  level  resource  to  a lower  level  resource,  and  the  capability 
must  exist  to  rapidly  communicate  bulk  data  from  lower  to  higher  security 
levels. 

ANALYSIS 

The  problem  at  GWC  is  one  of  authentication  protection  against  inadvertent 
exposure  due  to  hardware  failure  or  software  error.  The  SDC  approach  has  been 
the  use  of  coding  using  some  version  of  an  encoding  chip  which  renders  data 
unusable  and  unrecognizable  in  the  event  of  inadvertent  transfer  to  the  wrong 
recipient.  The  nonrecognition  of  code  actually  prevents  remaining  data 
from  being  transferred,  and  thus  this  is,  in  actuality,  an  authentication 
scheme;  however  the  encoding  of  data  protects  against  double  failures.  The 
difficulty  with  the  chip  approach  is  that  routing  must  take  place  after 
decoding  if  control  information  is  inherent  to  the  data,  or  routing  instructions 
must  exist  completely  independent  of  the  data,  say,  over  a control-only  data 
link.  Other  authentication  schemes  depend  on  switching  and  the  physical 
problems  of  initiating  a new  link  rapidly. 
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For  control-only  data  lines  the  options  exist  of  fixing  the  bandwidth  checking 
procedures,  or  allowing  operational  establishment  of  checking  procedures.  We 
have  chosen  the  later  approach. 

In  terms  of  switching  flexibility,  we  have  decided  to  simplify  the  problem 
by  only  allowing  automatic  switching  between  processors  and  the  data  base. 

We  further  feel  that  if  processors  are  only  required  to  interface  with 
contiguous  data  bases  (either  1,  2,  or  3 such  data  bases  depending  on  the 
physical  position  of  the  processor  within  the  system),  this  still  allows 
the  flexibility  to  meet  the  requirements. 

SUMMARY/CONCLUSIONS 

Two  parallel  upgrade  communication  links  as  well  as  the  control -only  data 
link  provide  the  necessary  capability.  A "wagon  wheel"  type  linkage, 
cuts  down  on  number  of  lines  and  channels.  Processors  are  allowed  to 
move  between  data  bases  by  virtue  of  their  permanent  connection  to  all 
data  bases  (but  with  authentication  compatibility  only  with  one). 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 
A20-1  through  A294-2 
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TRADEOFF  TITLE 

A21-1  What  is  the  nature  of  a control -only  data  connection? 
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REQUIREMENTS/BACKGROUND 

To  accommodate  the  network  control  task  and  requests  from  a higher  level 
machine  to  an  unclassified  data  base,  it  is  necessary  to  provide  a data  link 
from  a higher  level  machine  to  a lower  one. 

DESIGN  APPROACHES/CHARACTERISTICS 
(Also  see  A21-2) 

Besides  using  a manual  request  (which  would  not  meet  the  time  requirements),  the 
only  other  way  of  providing  data/action  would  be  without  communication  (i.e., 
preplanning  and  scheduling  all  upgrade  activities).  We  felt  this  to  be  a 
greater  problem  than  trying  to  design  a "control -only"  data  link. 

ANALYSIS 

It  has  been  established  that  under  specific  conditions  some  control  information 
may  flow  from  the  high-level  perimeter  to  the  low-level  perimeter.  One 
possible  arrangement  allowed  for  an  acknowledgement  (ACK)  or  negative  acknow- 
ledgement (NAK)  to  be  returned  from  the  high-level  periphery  to  the  low-level 
periphery.  The  suggested  scenario  screened  a string  of  ASCII  characters 
(eight  bits  each)  for  these  allowable  responses.  That  is,  two  characters  out  of 
the  total  of  2tt  (=256)  characters  is  cons1ai.vvd  an  acceptable  ratio.  Allowing 
two  characters  to  be  returned  also  means  that  ihould  an  accidental  error  cause 
a Top  Secret  binary  file  to  be  "dumped"  onto  ...  t physical  path,  then  probability 
indicates  that  2/256  of  the  data  will  pass  throuyii  as  bit  patterns  that  match 
the  ACK  and  NAK  characters  (and  of  course  all  mismatches  are  flagged  and  can 
result  in  discontinuing  the  data  flow). 

As  the  number  of  characters  allowable  increases  to  facilitate  sending  other 
responses,  which  we  will  call  control  data  information,  the  number  of  "hits" 
will  increase  proportionately.  If  we  allow  ten  such  allowable  control  data 
characters  to  indicate  such  things  as  "I  received  your  request  to  start  of  job", 
"your  job  start  request  cannot  be  honored",  or  the  like,  then  10/256ths  of  the 
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possible  bit  patterns  will  pass  through  unscathed  until  transmission 
halt  is  accomplished.  If  2/256  is  an  acceptable  ratio  then  what 
must  be  done  is  to  examine  a string  of  bits  wide  enough  to  allow  us  to  maintain 
the  2/256  ratio  for  a greater  number  of  allowable  responses.  This  would  require 
at  least  1280  possible  patterns  and  could  be  handled  with  an  eleven-bit  field 
(2^  = 2048  > 1280).  For  the  sake  of  convenience  a field  that  is  2 ASCII 
characters  wide  might  be  a more  useful  width  (14  bits  for  7-bit  ASCII  code  and 
16  bits  for  8-bit  ASCII  code).  This  would  allow  us  to  make  use  of  standard 
chips  for  shifting  and  examination. 


SUMMARY/CONCLUSION 

A simple  screening  device  can  be  used  to  filter  control  information  only.  This 
device  can  also  detect  and  terminate  the  entire  flow  of  data  when  other  than 
the  specifically  delimited  control  information  is  put  on  the  path,  thereby 
preventing  even  a percentage  of  data  from  passing. 

We  conclude  that  a one-way,  control -information-only  data  path  can  be  used  to 
provide  the  functionality  required  without  adding  a security  vulnerability  to 
this  environment. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  releated  to  the  following  requirements: 

100  - Special  Activities  - All 
200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 

RELATED  SPECIFICATIONS 

A20-1  through  A20-3,  A214-1,  A226-1  , A241-4,  A251-1,  A252-1  (e),  A291-4, 

A292-1  , A293-1  , A821-3,  A821-4 
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A22-1  How  do  you  effect  one-way  communication? 

REQUI REMENTS/BACKGRQUND 

In  the  configuration  proposed  by  SDC  it  is  desirable  to  have  a "one-way" 
connection  between  the  two  secure  environments.  In  particular,  it  is  desired 
that  this  connection  provide  a data  path  in  the  direction  from  the  low  security 
level  system  to  the  high-level  system.  This  is  in  accordance  with  the  security 
principle  that  forbids  a high  security  level  user  or  process  from  passing  data 
to  a lower  level  user  or  process.  For  practical  reasons,  it  is  also  desirable 
that  some  sort  of  acknowledgement  of  message  acceptance  (or  nonacceptance)  be 
given  to  the  message  sender.  Technically,* this  return  acknowledgement  is  in 
fact  an  information  path  that  would  be  illegal  according  to  the  security 
principle  just  mentioned. 

DESIGN  APPROACHES/CHARACTERISTICS 

If  we  are  not  concerned  about  the  malicious  user,  or  cooperating  with  malicious 
users,  we  can  limit  the  bandwidth  of  this  path  in  such  a way  that  we  have  some 
reasonable  assurance  that  "data"  are  not  flowing  through  this  path  illegally. 
For  example,  if  our  connection  is  made  up  of  a standard  RS232  line,  a typical 
sequence  might  be  that:  a)  A sends  a message  to  B,  and  b)  B sends  back  an 

ACK  or  NAK  response  character  indicating  reception  of  the  message  or  (possibly) 
an  error  condition  on  the  line.  Now  for  our  purposes  we  want  the  path  to  be 
one  way  so  we  cut  the  receive  wire  at  the  proper  point.  Now  A can  send  to  B 
but  can't  receive.  Unfortunately  A can  no  longer  receive  the  ACK  or  NAK 
characters  either.  So  we  can  see  that  a return  line  of  some  sort  must  go  from 
B to  A and  that  the  problem  is  one  of  limiting  the  bandwidth  of  the  path. 


ANALYSIS 

One  solution  would  be  to  insert  a black  box  in  the  return  line  that  will  allow 
only  certain  chiracters  to  be  returned.  Since  the  physical  mechanisms  actually 
used  in  this  type  of  configuration  are  in  fact  bit  serial,  the  black  box  device 
must  convert  to  characters  (bit  parallel),  examine  the  characters,  and  pass  on 
legal  characters  in  bit  serial  form.  A LSI  chip  exists,  called  UART  (Universal 
Asynchronous  Receiver/Transmitter),  that  will  perform  the  bit  serial/bit 
parallel  function.  Using  these  chips  a black  box  that  will  provide  the  proper 
"one-way"  functionality  could  be  built  for  about  $200. 


SUMMARY/CONCLUSION 

One-way  communication  can  be  effected  by  limiting  the  bandwidth  of  the  data 
path  and  checking  for  valid  data  passage. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special  Activities  - All 
200  - Command  and  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 


RELATED  SPECIFICATIONS 

A20-1 , A213-1,  A241-3,  A291-5,  A821-15,  A821-21 
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TRADEOFF  TITLE 


A22-2  How  will  authentication  be  used  for  the  "switching"  of  components  within 
the  data  system? 

REQUIREMENTS/BACKGROUND 

To  accommodate  the  network  control  approach  there  must  be  a technique  included 
in  the  design  to  perform  rapid  switching  while  protecting  the  security  integrity 
of  the  data  within  the  components.  It  has  been  established  that  currently 
available  techniques  of  software  protection  are  not  adequate. 

DESIGN  APPROACHES/CHARACTERISTICS 

Two  fundamental  approaches  exist:  a)  physically  switching  components  with 

manual  certification  that  switching  has  indeed  taken  place  and  b)  authentication 
which  involves  encoding  of  data  when  they  leave  one  component  with  decoding 
when  they  arrive  at  another.  The  keys  for  encoling  are  only  available  to 
components  with  the  appropriate  level. 

ANALYSIS 

A very  simple  device  could  be  constructed  that  could  provide  what  can 
be  called  "protective  switching".  That  is,  devices  can  be  separated  by  encoding 
devices  that  allow  communication  only  according  to  some  specific  set  of  rules. 
For  example,  these  rules  might  be  as  follows: 


DEVICE  SECURITY  LEVEL 

CAN  SEND  TO 

CAN  RECEIVE  FROM 

TS 

TS 

TS,  S,  U 

S 

S,  TS 

S,  U 

U 

U,  S,  TS 

U 

The  rules  could  be  implemented  in  a microprocessor-driven  device  that 
makes  use  of  a chip  in  the  following  manner.  The  microprocessor 
maintains  a table  of  keys  that  it  uses  in  deciphering  and  enciphering  data. 

Each  message  would  have  a tag  "in  the  clear"  indicating  the  level  of  the 
message.  This  tag  would  tell  the  receiver  which  key  to  use  to  decipher  the 
message.  Keys  would  be  set  up  such  that  devices  can  only  send  with  the  key 
equal  to  their  own  level  and  such  that  devices  would  not  have  the  keys  for 
levels  greater  than  their  own.  Even  if  a tag  is  sent  incorrectly,  a particular 
receiving  device  would  not  have  the  proper  key  to  decipher  messages  sent  from 
a higher  level. 

Keys  could  be  stored  on  PROMS  (Programmable  Read  Only  Memories)  that  plug 
into  the  encoding  devices  themselves.  To  change  the  level  of  a device,  a 
new  key  could  be  made  available  from  network  control. 

The  key  tables  for  each  level  might  look  like  this: 


UNCLASSIFIED 

SECRET 

TOP  SECRET 

TAG 

UNC 

SEC 

TS 

Send  Key 

Ku 

Ks 

Kts 

Receive  TS  Key 

-- 

-- 

Kts 

Receive  S Key 

-- 

Ks 

Ks 

Receive  U Key 

Ku 

Ku 

Keys  could  be  generated  off-line  and  written  into  the  PROMs  by  a general-purpose 
computer  using  suitable  randomization  techniques. 


An  alternate  method  of  updating  the  keys  would  be  to  have  a dedicated 
micro-  or  minicomputer  to  distribute  the  keys  as  required,  under  the  direction 
of  the  network  control  officer.  Because  this  computer  would  not  be  available 
for  general  programming  the  task  of  verifying  the  distribution  of  the  keys  is 
made  much  easier.  Using  this  automated  scheme  for  distribution  of  keys  would 
allow  for  security  reconfiguration  in  a matter  of  seconds.  The  limiting  factor 
would  be  how  fast  the  operational  parts  of  the  system  can  reconfigure  the 
components. 

Note  that  in  this  case  encoding  is  being  used  to  ensure  that  devices  are 
correctly  switched  together,  it  is  not  being  used  to  protect  data  from  the 
system  penetrator  and  therefore  even  a simple  algorithm  would  suffice. 

Data  rates  for  proposed  chips  will  be  fast  enough  to  handle  channel  rates. 

The  speed  limitations  appear  to  be  in  the  microprocessor  that  is  used  to  * 
drive  the  crypto  device.  However,  all  the  microprocessor  has  to  do  is 
select  the  keys  and  feed  the  crypto  chip.  Because  of  the  small  processor 
requirements  a small  (4-bit),  fast  microprocessor  could  be  used.  The  cost 
for  such  a device  would  probably  be  in  the  low  four-figure  range. 

Also  note  that  the  actual  physical  links  between  the  devices  are  still  of 
concern.  The  two  methods  of  doing  this  that  have  been  proposed  are  with  actual 
physical  bus  switcher  or  by  using  networking  concepts. 

In  the  case  where  we  have  communications  lines  of  various  levels  entering  the 
security  periphery,  the  data  could  be  enciphered  immediately  at  the  point  the 
lines  enter  the  periphery. 
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SUMMARY/CONCLUSION 


An  authentication  technique  involving  a microprocessor-driven  chip  can  be 
used  to  ensure  that  components  that  have  the  capability  of  being  switched 
from  one  system  to  another  are  incapable  of  violating  security  rules.  Keys 
associated  with  various  security  levels  can  be  distributed  either  manually 
or  automatically. 

We  conclude  that  encoding  authentication  of  the  switching  of  devices  is 
a reasonable  and  practical  method  of  ensuring  that  a given  configuration  is 
incapable  of  causing  security  violations  due  to  misdelivery  or  misrouting 
of  data. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special  Activities  - All 
200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 

RELATED  SPECIFICATIONS 

A20-1 , A20-2,  A211-1  through  5,  A22-1  through  3,  A221-1  through  7,  A223-1  , 2, 
A215-1 , A225-1  , A221-3,  A241-11,  A252-1  , A813-21,  A821-2,  6,  G40-2 


TRADEOFF  TITLE 


A22-3  What  role  should  authentication  chips  and  switches  have  in  the  design? 
REQUIREMENTS/BACKGROUND 

To  provide  the  functionality  required,  two  important  concepts  must  be  met: 

a.  CPUs  and  perhaps  other  devices  must  be  switchable  from  one  system 
to  another  with  a minimum  amount  of  difficulty. 

b.  The  security  level  of  processing  systems  must  be  changeable  at  the 
discretion  of  the  proper  authority. 

DESIGN  APPROACHES/CHARACTERISTICS 

Switching  can  be  accomplished  either  via  hardware  or  software  mechanisms. 
Hardware  switching  would  involve  the  development  of  a switching  device  or 
bus  with  automatic  control  to  meet  timing  requirements.  This  might  involve 
a very  substantial  and  expensive  engineering  effort  if  difficulties  existed 
in  bringing  up  a connection.  We  believe  that  the  alternative  approach  of 
providing  software  switching  is  more  feasible  but  we  cannot  depend  on 
software  as  a solution  to  the  separation/authentication  problem. 

In  either  case  the  switching  must  be  verifiable.  Handshaking  for  authenti- 
cation is  one  possibility  or  the  embedding  of  recognizable  data  to  ensure 
that  security  rules  cannot  be  violated  effective  and  inexpensive  ways  to 
provide  a measure  of  confidence  in  the  validity  of  the  system  configuration. 
Some  devices  are  not  "smart"  however  (such  as  controllers)  and  cannot  handle 
a complex  logic  requirement.  Extensive  hardware  modification  is  expensive. 
Encoding  the  whole  stream  as  an  authentication  approach  seems  more  reasonable. 

ANALYSIS 


Techniques  and  concepts  for  switching  computer  system  components  are  developing 
most  rapidly  in  the  area  of  computer  networking.  Sufficient  work  in  this  area 
has  been  done  to  show  that  by  using  "front-end"  devices  and  message  switching 
techniques,  devices  can  be  effectively  coupled  to  provide  the  dynamic 
functionality  required  for  this  application. 
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We  have  also  done  considerable  checking  in  the  area  of  the  effective  use  of 
cryptographic  and  encoding  chips.  We  have  found  that  an  encoding/decoding 
chip  device  can  be  built  inexpensively  (less  than  $10,000)  which  will  provide 
positive  ensurance  that  security  rules  are  not  violated.  When  used  in 
combination  with  visable  features,  the  data  interface  is  clear  or  simply 
even  in  the  event  of  misrouting. 

SUMMARY/CONCLUSIONS 

CPUs  and  other  devices  can  be  switched  either  physically  or  under  some 
software  control.  In  either  case  the  "switched"  systems  must  be  verified 
extensively. 

We  can  conclude  that  software  switching  using  networking  concepts  augmented 
with  authentication  coding  will  provide  the  security  and  operational 
functionality  required. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special  Activities  - All 
200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 

RELATED  SPECIFICATIONS 

A20-1 , 2,  A211-1  through  5,  A22-1  through  3,  A221-1  through  7,  A223-1  , 2, 
A215-1 , A225-1  , A221-3,  A241-11,  A252-1  , A813-21,  A821-4,  6,  G40-2 
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TRADEOFF  TITLE 

A24-1  Shpuld  the  master  data  base  processor  transfer  data  to  the  requesting 
processor  or  directly  to  disk? 

REQUIREMENTS/BACKGROUND 

* 

The  AFGWC  Master  Data  Base  is  to  be  centrally  located  as  a set  of  files  in 
auxiliary  storage  (e.g.,  disks)  which  are  accessible  only  by  the  processor 
executing  the  data  base  maintenance  programs.  Copies  of  portions  of  the  data 
base  will  be  made  and  transferred  on  request  to  processors  on  which  jobs  are 
being  set  up  that  require  the  data. 

DESIGN  APPROACHES/CHARACTERISTICS 

In  providing  extracts  from  the  Master  Data  Base  to  processors  which  request 
them,  the  urgency  of  the  request  and  the  timeliness  of  the  data  are  both 
important  factors  to  be  considered.  The  method  to  be  employed  in  transferring 
the  data  is  determined  by  these  factors:  the  volume  of  data  requested,  access- 

ibility of  the  destination  medium,  and  security  constraints.  It  is  character- 
istic of  AFGWC  programs  that  the  fields  of  the  data  base  which  are  needed  by 
each  program  are  known  in  advance.  We  assume  that  it  is  generally  possible  to 
schedule  a job  sufficiently  in  advance  to  have  the  required  data  extracted  from 
the  Master  Data  Base  and  placed  in  an  accessible  location  for  use  by  the  program 
prior  to  its  execution. 

ANALYSIS 

If  data  are  to  be  sent  to  the  requesting  processor  it  is  necessary  to  synchronize 
the  activities  of  the  data  base  processor  and  the  requesting  processor.  Either 
the  data  base  processor  must  retain  the  data  in  its  main  memory  until  the  job 
which  requires  it  is  activated,  or  the  requesting  processor  must  provide  buffer 
space  in  its  main  memory  to  receive  and  retain  the  data  until  the  job  is 
activated,  or  the  data  are  not  extracted  from  the  data  base  until  the  job  is 
activated.  The  last  option  should  be  excluded  when  it  is  inconsistent  with 
the  goal  of  providing  all  necessary  data  in  advance  of  a job  in  order  to  avoid 
delays  in  extracting  from  the  Master  Data  Base.  The  second  alternative  is  not 
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always  desirable,  since  it  ties  up  resource  of  the  requesting  processor 
(main  memory)  for  storage  of  data  which  cannot  be  referenced  until  the 
relevant  job  starts.  The  first  alternative  is  advantageous  from  the  point  of 
view  of  the  requesting  processor,  but  includes  two  undesirable  attributes 
insofar  as  the  data  base  processor  is  concerned:  (1)  considerable  main  memory 

may  be  tied  up  with  waiting  portions  of  data  bases  (even  to  the  point  of 
saturating  the  main  memory  capacity  of  the  data  base  processor),  and  (2)  block 
data  transfer  between  main  memories  occurs  at  the  maximum  rate  of  the  slower 
of  the  two  memory  units,  which  is  expected  to  be  sufficiently  high  as  to 
preclude  other  simultaneous  I/O  operations.  Furthermore,  the  direct  interface 
between  processors  for  synchronization  and  data  transfer  may  present  signifi- 
cant problems  if  the  status  of  the  receiving  processor  is  not  known. 


If  requested  data  are  buffered  tc  a shared  auxiliary  storage  unit  (e.g., 
disk),  the  difficulties  associated  with  the  approaches  discussed  above  are 
avoided.  Synchronization  is  not  required,  and  the  highly-valued  main  memory 
is  not  tied  up  unnecessarily.  An  additional  benefit  derives  from  the  fact 
that  the  processor  which  requests  the  data  and  the  processor  which  ultimately 
performs  the  job  that  requires  it  need  not  be  the  same.  This  permits  a 
centralized  job  scheduler  and  network  controller  to  direct  the  data  base 
management  program  to  extract  portions  of  the  Master  Data  Base  for  delivery  to 
a disk  at  the  appropriate  classification  level  for  subsequent  use  by  a job; 
the  job  will  be  assigned  to  a processor  which  is  cleared  for  the  security 
level  and  which  is  able  to  access  the  disk  through  the  configuration  existent 
at  that  stage. 

SUMMARY/CONCLUSIONS 

The  master  data  base  processor  should  have  the  capability  to  transfer  requested 
data  to  both  localized  disk  and  directly  to  processors  for  use  by  application 
programs. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 

A20-2,  A20-3,  A20-7,  A215-1,  A223-1 
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TRADEOFF  TITLE 

A24-2  How  do  we  deal  with  incompatible  interfaces  and  what  will  be  the 
associated  costs? 


REQUIREMENTS/BACKGROUND 

The  1975-1982  GWC  data  processing  system  will  be  a "mixed  system  configuration" 
i.e.,  a configuration  consisting  of  both  standard  and  non-standard  computers 
and  peripheral  equipment.  Being  a "mixed  system  configuration",  problems  with 
equipment  compatibility  and  interfacing  can  be  expected. 

Compatibility  between  computers  and  peripherals  requires  attention  to  both 
hardware  and  software  differences.  Hardware  differences  may  involve  speed, 
code,  timing,  word  length,  logic  state  definition,  and  driver  and  receiver 
characteristics.  One  of  the  most  important  hardware  considerations  is  the 
speed  of  operation  between  units.  Major  differences  in  operational  speed 
requires  a buffering  interface.  For  software  compatibility  all  interconnected 
units  must  interpret  the  same  bit  sequence  in  the  same  way  and  the  form  of 
bit  transmission,  serial  or  parallel,  if  not  compatible  must  be  made  so  by  an 
interface. 

An  additional  consideration  for  incompatible  data  processing  devices  are  the 
control  signals  that  synchronize  and  control  the  flow  of  data.  These  signals 
may  be  on  single  or  parallel  lines  operated  as  simplex  or  duplex  transmission 
paths  and  may  be  multiplexed.  For  logic  compatibility,  control  signals  and 
the  timing  of  these  signals  between  interconnected  units  must  be  understood  and 
taken  into  account. 


DESIGN  APPROACHES/CHARACTERISTICS 

For  analysis  purposes,  an  incompatible  interface  is  defined  as  an  interface 
between  equipment  for  which  no  interfacing  responsibility  has  been  established 
for  the  supplier  of  the  equipment.  The  design  approach  to  solving  incompatible 
data  system  interfaces  will  be  as  follows: 
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a. 


Maximize  the  equipment  procured  from  a given  manufacturer  to 
minimize  incompatible  interfaces. 


b.  Utilize  applicable  special  computer-oriented  interface  modules  to 
avoid  the  construction  of  tailored  interface  hardware. 


c.  Utilize  mini  computers  for  complex  incompatible  interfaces. 


ANALYSIS 

Specific  incompatible  interfaces  can  only  be  defined  from  a detailed  design 
of  a finalized  system  configuration.  The  technical  tradeoffs  that  will  be 
required  for  this  detailed  design  will  be  dependent  on  the  specific  charac- 
teristics of  hardware  units  to  be  interfaced. 

The  current  availability  of  a wide  variety  of  interface  modules  from  data 
processing  equipment  suppliers  and  the  development  of  mini  computers  has  made 
it  much  easier  to  solve  data  transfer  and  routing  incompatible  with  off-the- 
shelf  hardware.  A review  of  current  trade  literature  indicates  that  following 
a detailed  design  of  the  AFGWC  system  the  resolution  of  incompatible  interfaces 
will  not  be  a serious  problem. 

A possible  example  of  an  incompatible  interface  is  between  the  proposed 
dedicated  small  (16  bit)  mini  computer  for  the  Automated  Work  Centers  and  the 
Univac  system  processors.  In  all  probability  an  interface  module  incorporating 
address  selection,  interrupt  control,  data  reformatting  and  impedance  matching 
will  be  required. 

SUMMARY/CONCLUSIONS 

a.  Specific  incompatible  interfaces  for  the  AFGWC  system  configuration 
can  only  be  defined  for  a unique  final  configuration  with  specific 
hardware  characteristics. 

b.  A wide  variety  of  interface  module  hardware  is  available  as  off-the- 
shelf  hardware. 
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c.  The  use  of  mini  computers  to  meet  data  processing  interface 
incompatibilities  is  now  a developed  and  accepted  technique. 

d.  The  cost  of  interface  modules  or  mini  computers  required  to  overcome 
operational  differences  between  two  devices  is  expected  to  range  from 
$8,000  to  $15,000  for  most  GWC  incompatible  interfaces. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

601  - General  - Growth 

RELATED  SPECIFICATIONS 
A27-1 , 2 
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TRADEOFF  TITLE 


Mm 


A24-3  Should  mini -computers  be  used  for  complex  incompatible  component 
interfaces? 


REQUIREMENTS/BACKGROUND 

The  future  AFGWC  system  will,  like  the  current  system,  necessarily  include  a 
variety  of  components  which  must  communicate  with  each  other  for  data  transfer 
and  control.  A significant  portion  of  the  system  design  effort  must  be 
devoted  to  specification  of  active  interfaces  between  components  to  overcome 
incompatibility. 

DESIGN  APPROACHES/CHARACTERISTICS 

A significant  development  of  standardized  interfaces  has  been  occurring  over 
the  last  several  years  in  the  computer  industry.  This  has  been  concentrated 
principally  on  providing  off-the-shelf  hardware  modules  for  interfacing  system 
components  with  computers,  especially  mini  computers.  These  modules  can  be 
selected  and  tailored  (often  using  microprogramming)  to  provide  compatibility 
in  speed,  code,  timing,  word  length,  logic  state  definition,  and  driver  and 
receiver  characteristics.  It  is  more  cost  effective  to  employ  such  readily 
available  devices  than  to  construct  special  interfaces  for  each  of  the  inter- 
communication paths  of  the  AFGWC  system. 

ANALYSIS 

Interfaces  within  the  AFGWC  system  which  involve  a computer  on  one  or  both 
sides  (or  a computer  data  bus)  can  either  be  supplied  by  the  computer  vendor  - 
if  the  component  on  the  other  side  of  the  interface  is  manufactured  by  the 
same  vendor  - or  be  developed  from  standardized  interface  modules.  This  is 
not  true  of  interfaces  between  two  non-computer  components  of  different 
manufacture.  To  deal  effectively  with  this  latter  situation,  a mini-computer 
should  be  interjected  in  the  path,  in  order  that  the  standard  interface 
modules  might  be  used. 
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SUMMARY/CONCLUSION 

« | j + 

Mini-computers  should  be  used  for  complex  incompatible  interfaces. 
RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 


A27-1 , 2 
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TRADEOFF  TITLE 

A29-1  Should  there  be  a total  system  protocol  for  devices? 
REQUIREMENT/BACKGROUND 

Total  system  protocol  for  data  transfer  and  routing  consists  of  the  standards 
and  conventions  defined  for  the  operational  use  of  the  hardware  units  within 
the  system. 

For  all  large  systems,  software  or  hardware,  the  establishment  and  implementa- 
tion of  standards  and  conventions  is  an  ongoing  process  refined  throughout  the 
life  of  the  system. 

The  design  decisions  formulated  in  the  task  2 effort  in  respect  to  total 
system  protocol  are  not  intended  to  be  final  or  all  inclusive  but  are  intended 
to  identify  those  areas  of  profitable  standardization  and  good  practice  which 
can  serve  as  a base  for  uniform  design. 

DESIGN  APPROACHES/CHARACTERISTICS 


All  data  transfer  and  routing  within  the  GWC  data  processing  center 
will  be  performed  via  specific  operation  standards  and  conventions. 

All  data  transfer  and  routing  operations  shall  identify  the  security 
level  of  the  data  involved  and  the  data  transfer  and  routing  shall  be 
made  in  a manner  that  makes  physical  violation  of  its  security  level 
impossible. 

All  automatic  switching  and  routing  devices  shall  have  an  available 
manual  backup. 

After  a data  base  defined  number  of  unsuccessful  attempts  to  transfer 
data,  a network  control  function  modification  shall  be  generated. 

Ready-to-receive  and  data-received  messages  shall  be  phased  and 
routed  in  a manner  that  prevents  degrading  of  any  data  transferred. 

Data  transfers  shall  follow  specific  procedures  established  to 
prevent  loss  of  data. 
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System  data  routing  shall  be  optimized  in  respect  to  the  number  of 
users  of  the  data  in  order  to  reduce  redundant  operations. 

All  processors  shall  have  a capability  to  output  data  to  a spooled 
buffer  for  printer  output. 

Explicitly-defined  standards  will  be  followed  in  data  transfer  and 
routing  messages. 

Entry  to  any  data  to  be  transferred  or  routed  must  be  via  authorized 
control  procedures. 

A priority  procedure  for  both  critical  and  non-critical  operations 
will  exist  in  the  network  control  system. 


1. 


The  primary  criterion  for  grouping  data  shall  be  frequency  of  use 
of  the  established  specialized  data  bases. 


ANALYSIS 


A conceptual  analysis  of  total  system  protocol  for  devices  can  only  be  performed 
as  a task  to  define  the  operational  standards  and  conventions  for  the  finalized 
AFGWC  system  configuration. 


SUMMARY/CONCLUSIONS 

Operational  standards  and  conventions  must  be  defined  and  implemented  to  insure 
meeting  the  proposed  AFGWC  system  design  specifications. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 
No  requirements. 


RELATED  SPECIFICATIONS 
A291-1  through  7 
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TRADEOFF  TITLE 

A29-2  What  should  be  established  for  satellite  data  reception,  processing  and 
output  protocol? 

REQUIREMENTS/BACKGROUND 

Satellite  weather  data  images  will  be  generated  by  the  AFGWC  data  processing 
system  on  both  a scheduled  and  a special  request  basis  and  delivered  to  SID 
users.  To  facilitate  the  reception,  processing  and  output  product  generation 
of  SID  products,  an  operational  protocol  is  required  which  will  be  compatible 
with  the  overall  operational  schedules  and  capabilities  of  the  hi  v-WC  system. 

DESIGN  APPR0ACHES/CHARACTERIS1  ICS 

The  design  approach  to  the  reception,  processing  and  product  generation  of 
satellite  weather  data  is  to  provide  a system  which  can  be  initialized  by  a 
single  operator  input  that  will  execute  all  required  functions.  These 
functions  will  be  performed  by  the  systems  processors  following  preprocessing 
by  a mini-computer  and  will  be  made  available  to  a Satellite  Data  Subsystem 
mini -computer  for  both  scheduled  and  special  request  products. 

ANALYSIS 

The  initialization  of  the  AFGWC  data  processing  system  to  acquire  and  process 
satellite  data  will  be  a single  input  request  from  a system  operation  which 
will  be  exercised  following  voice  communications  of  data  arrival  time  from 
primary  satellite  data  readout  sites.  All  incoming  satellite  data  will  be 
preprocessed  by  a satellite  preprocessor  mini-computer  followed  by  predefined 
processing  and  storage  in  the  satellite  data  base.  The  satellite  preprocessing 
mini-computer  will  provide  an  end-of-data  ingestion  message  to  the  satellite 
data  processor  which  will  terminate  operations  through  the  network  control 
system. 
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The  SID's  mini -computer  will  interface  with  the  network  scheduling  system  to 
request  both  normally  scheduled  and  special  SID  products.  These  products  will 
be  produced  by  an  assigned  processor  and  held  in  temporary  mass  storage  until 
output  to  the  user. 

SUMMARY/CONCLUSION 

The  architecture  will  assume  the  existence  of  a processing  ground  station  for 
each  of  the  Satellite  data  inputs:  DMSP,  TIROS-N,  GOES  and  Foreign  GOES. 

(The  use  of  a single  console  or  tape  recording  device  will  be  transparent  to 
the  architecture.) 

The  functions  of  photo  data  hardcopy  output  and  AGE  image  processing  will  be 
accommodated  elsewhere  within  the  system  (via  CRT  hardcopy  and  high  resolution 
data  processing  respectively). 

The  capability  will  exist  to  filter  satellite  data  based  on  data  base  specified 
criteria  relating  to  time  on  geographic  criteria  (e.g.,  land  mass)  representing 
the  culmination  of  current  processing  requirements. 

The  SID  interface  will  be  automated  via  a minicomputer  with  a backup/optional 
standard  tape  drive  interface. 

The  SID  interface  will  accept  gridded  imagery  produced  by  the  vehicle  dedicated 
interface  subsystem  (Site  III,  DUS)  or  via  computer  reconstituted  imagery. 
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RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special  Activities  - All 

208  - Command  Control  Systems  - TAC 

300  - Emergency  War  Order  Support  - All 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

RELATED  SPECIFICATIONS 

A291-1,  3,  4,  A292-3,  A294-1 , 2,  A452-2,  3,  4,  A461-1 


TRADEOFF  TITLE 


A30-1  What  is  the  tradeoff  between  heterogeneous  system  and  software  costs? 
REQUIREMENTS/BACKGROUND 

When  two  or  more  different  types  of  computers  are  to  be  combined  in  a data 
processing  system,  the  effects  upon  software  development  and  maintenance 
should  be  examined  from  several  aspects.  The  most  obvious  problem  is  in  the 
area  of  intercomputer  communication.  However,  there  are  several,  potentially 
more  significant,  problem  areas  to  be  considered.  For  example,  two  or  more 
command  or  control  languages  must  be  employed  to  submit  programs  to  the  com- 
puters and  invoke  utility  and  compilation  functions,  and  debugging  programs 
on  each  computer  requires  knowledge  of  the  internal  work  structure  and  instruc 
tions. 

DESIGN  APPROACHES/CHARACTERISTICS 
(see  ANALYSIS) 

ANALYSIS 

For  each  function  to  be  programmed  by  GWC,  a decision  must  be  made  as  to  which 
computer  or  computers  is  to  perform  the  function.  If  more  than  one  type  of 
computer  must  be  able  to  handle  the  function,  a further  decision  must  be  made 
as  to  whether  it  can  be  programmed  in  a common  subset  of  a higher  level 
programming  language, which  would  permit  its  compilation  for  the  pertinent 
computers  if  it  must  be  encoded  two  or  more  times  for  the  computers.  (The 
former  method  should  be  considered  as  good  programming  practice  by  GWC  in 
any  case,  since  the  life  expectancy  of  the  GWC  software  may  well  span  more 
than  one  evolutionary  stage  in  hardware.)  Regardless  of  the  outcome  of  this 
decision  process,  programmers  who  code  a function  for  a computer  must  be 
familiar  with  the  form  of  data  representation  in  the  computer,  the  command  or 
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control  language  required  to  compile  and  run  programs,  and  the  diagnostic  and 
debugging  tools  and  reports  associated  with  the  computer.  They  must  also  be 
prepared  to  deal  with  the  instruction  set  and  word  structure  of  the  computer 
if  they  are  to  use  memory  dumps,  tracing,  and  patching  techniques. 

Intercomputer  communication  and  data  representation  among  differing  computers 
may  present  major  problems  in  software  development.  Even  for  interfaces 
among  computers  produced  by  the  same  vendor,  there  may  be  inadequate  software 
for  control  communication,  and  GWC  would  necessarily  assume  full  responsibility 
for  development  of  interfaces  for  control  and  data  transfer  between  computers 
produced  by  different  vendors.  Unless  data  representation  is  virtually 
identical  in  all  of  the  interconnected  computers,  decisions  will  be  required 
regarding  the  methods  to  be  used  in  representing  stored  data,  and  data  for 
processing  or  intercomputer  transfer,  and  in  determining  how  data  bases  are 
to  be  accessed  ( i . e. , will  they  be  directly  accessible  by  dissimilar  computers, 
or  must  one  type  of  computer  manage  data  bases  and  convert  data  formats  and 
representations  for  transfer  from  and  to  other  computers?).  Factors  to  be 
considered  in  data  representation  include: 

word  size, 

floating  point  (precision,  exponent/mantissa  format), 
sign  (l's  complement,  2's  complement,  sign  field), 
character  (ASCII,  BCD,  EBCDIC),  and 
numbers  (binary,  hexadecimal,  decimal). 

Finally,  operating  systems  and  utility  packages  which  are  vendor  supplied 
generally  require  tailoring  to  the  installation  configuration  and  continuing 
maintenance  to  ensure  parity  with  subsequent  operating  system  releases.  If 

more  than  one  type  of  computer  is  incorporated  in  the  system,  this  effort  is 
further  complicated. 

SUMMARY/CONCLUSION 

None  of  the  questions  raised  in  the  above  discussion  can  be  answered  at  this 
stage  of  system  design.  However,  they  must  be  kept  in  mind  during  the  analysis 
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and  selection  process  for  components  of  the  GWC  system,  as  the  factors  discussed 
will  greatly  affect  the  cost  and  effort  of  programming  the  system. 


RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements: 


600  - General  - All 


RELATED  SPECIFICATIONS 

A311-1  through  7,  A312-1  through  A312-39,  A313-1  through  A313-4,  A313-8,  12,  13 


TRADEOFF  TITLE 


A30-2  What  is  the  cost  of  interfacing  systems  from  two  vendors? 


REQUIREMENTS/BACKGROUND 

The  nature  of  the  configuration  suggested  by  this  study  and  the  hardware  pro 
curement  practices  to  be  followed  suggest  the  possibility  of  a final  system 
with  hardware  from  mixed  sources  (i.e.  vendors). 

There  may  be  some  significant  additional  costs  involved  in  interfacing  the 
different  types  of  hardware  which  must  be  investigated. 


DESIGN  APPROACHES/CHARACTERISTICS 

Hardware  interface  design  costs  were  considered  only  implicitly.  That  is, 
no  attempt  was  made  to  calculate  these  costs  due  to  the  complexity  of  possible 
combinations  of  vendors.  Rather,  the  costs  of  hardware  were  rounded  up, 
and  in  the  case  of  multiple  possible  vendors,  the  maximum  cost  was  used 
rather  than  an  average  cost.  This  approach  is  quite  conservative,  considering 
that  the  total  data  system  hardware  cost  totaled  tens  of  millions,  and  inter- 
facing costs  around  tens  of  thousands  for  each  case. 


ANALYSIS 


Some  idea  of  interfacing  costs  can  be  had  from  the  following  table  of  vendor 
estimates : 


VENDOR 


Floating  Point  Systems,  Inc.  Array  Processor  $ 6,000  - $10, 000/unit 

Datawest  Corporation  Array  Processor  $15,000  - one-time 

engineering 
$ 7,000  - $ 8,000/unit 

Estimates  are  for  attaching  array  processors  to  Uni  vac  1100  channels. 


SUMMARY/CONCLUSION 

It  is  felt  that  initial  hardware  costs  outweigh  interfacing  costs  to  such 
an  extent  that  the  latter  can  be  considered  as  implicit  in  the  initial  pur- 
chase cost. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

600  - General  - All 

RELATED  SPECIFICATIONS 
None 
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TRADEOFF  TITLE 


( 

V 


A30-3  What  is  the  breakdown  of  an  average  GWC  function  into  wait,  transfer, 
and  compute  time  for  the  different  computer  sizes? 


REQUIREMENTS/BACKGROUND 

The  wall  time  of  an  average  function  run  on  GWC  facilities  has  been  estimated 
to  consist  of  the  following  components: 


wait  time 

39.0% 

transfer  time 

27.3%  ) 

overlap  between  transfer 

compute  time 

47.1%  j 

and  compute  * 13.4% 

These  numbers  are  based  on  functions  running  on  a UNIVAC  1108  processor.  To 
determine  the  number  of  large  processors  required  to  meet  GWC  requirements, 
these  new  wait/ transfer/compute/overlap  times  must  be  examined. 


DESIGN  APPROACHES/CHARACTERISTICS 
(see  Analysis) 


ANALYSIS 

Decision: 

computer 

MIP 

compute 

% 

1108 

.75 

47.1 

1110  (lxl) 

1.4 

54 

1100/40 

2.6 

351 

CYBER  175 

6.2 

17l 

IBM  370/195 

12.5 

0.51 

transfer 

overlap 

wait 

% 

% 

% 

27.3 

13.4 

39 

282 

203 

404 

352 

203 

504 

412 

!73 

594 

41 2 

8.55 

594 

(Superscripts  defined  on  next  page.) 
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Superscripts: 

1.  Determined  by  applying  faster  MIP  rate. 

2.  Assume  transfer  rate  increase  by  factor  of  2 due  to  faster  disk 
(8440  vs  8433),  and  the  effect  of  using  more  main  memory  which  will 
result  in  more  data  being  kept  in  core,  hence  fewer  disk  accesses. 

3.  Assume  ideal  maximum  overlap  of  20%  of  wall  time. 

4.  Assume  that  all  of  wait  time  was  due  to  disk  and  this  has  decreased 
by  factor  of  2,  due  to  the  use  of  disks  with  smaller  rotational 
delays  and  due  to  more  paths  to  a given  disk  (multiple  control  units). 

5.  When  compute  drops  below  20%,  assume  all  compute  is  overlapped  with 
transfer. 

SUMMARY  CONCLUSION 

In  general,  machines  which  can  compute  faster  will  begin  to  be  limited  by 
their  transfer  rates.  This  means  that  for  an  "average"  GWC  function  all 
compute  time  will  eventually  be  overlapped  with  transfer  time  and  this 
limiting  case  will  then  break  wall  time  down  to  41%  transfer  and  59%  wait. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

600  - General  - All 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 

A30-4  What  is  the  tradeoff  between  retaining  RTOS  along  with  required  upgrades 
and  starting  from  scratch? 

REQUIREMENTS  BACKGROUND 

RTOS  (Real  Time  Operating  System)  is  a very  large  routine  written  entirely 
in  assembly  language.  As  the  functions  which  RTOS  must  accomplish  evolve 
and  new  hardware  is  acquired,  upgrades  become  extremely  complicated  and  costly. 

DESIGN  APPROACHES/CHARACTERISTICS 
(see  ANALYSIS) 

ANALYSIS 

This  question  has  to  be  postponed  until  more  is  known  about  the  ultimate 
configuration.  If  the  computer  hardware  with  which  RTOS  must  interface  is 
other  than  UNIVAC,  an  entire  rewrite  from  scratch  will  probably  be  necessary 
due  to  language  and  structure  incompatibilities.  Even  if  the  present  rela- 
tionship with  UNIVAC  is  retained  it  will  most  likely  not  be  able  to  react  to 
necessary  change  smoothly  and  efficiently. 

SUMMARY/CONCLUSION 

Upgrading  versus  completely  rewriting  RTOS  must  be  left  as  an  option. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

200  - Command  Control  Systems  - All 

300  - Emergency  War  Order  Support  - All 

500  - Space  Environment  Support  - All 

409  - Environmental  Support  - Operations  Security 

416  - Environmental  Support  - Backup  to  Carswell 


RFLATED  SPECIFICATIONS 


u 


TRADEOFF  TITLE 


A30-5  What  is  the  minimum  number  of  a single  size  of  computer  required  to 
meet  GWC’s  needs? 


REQUIREMENTS/BACKGROUND 

This  study  is  essentially  a continuation  of  A30-3  which  breaks  down  the  expected 
wall  time  of  an  average  GWC  function  for  the  different  computer  sizes.  Once 
the  makeup  of  the  wall  time  is  understood,  we  can  determine  the  number  of 
processors  required  to  handle  the  expected  load  of  functions. 


DESIGN  APPROACHES/CHARACTERISTICS 

This  estimate  will  not  take  into  account  security  and  reliability  since  these 
depend  on  an  overall  configuration.  The  numbers  which  follow  attempt  to 
judge  the  number  of  processors  needed  to  independently  accomplish  the  models' 
remaining  requirements. 


ANALYSIS 

Results  of  Study: 
number  of  processors  required 


nominal  load 


peak  load 


1 

computer 

RP 

other 

requirements 

mode ) s 

other 

requirements 

1108 

1 

6 

__ 

14 

1110  (lxl) 

1.8 

4 

_ _ 

8 

1100/40 

3.5 

2 

_ _ 

4 

CYBER  175 

6.3 

1 

2 

IBM  370/195  or 

13.5 

1 

4 

1 

PkOTEUS 

50 

— 

3 

60 

— 

3 

95 

— 

2 

— 

model s 


(the  dashes  indicate  the  computer  has  no  application  for  the  given  requirements) 


t 


f 

I 


if 
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The  numbers  for  "other  requirements"  have  been  derived  from  "average" 
statistics  for  function  wail  time  determined  in  A30-3  for  five  different  computer 
rates*  (The  final  three  are  igrfored  since  they  are  special -purpose  computers 
which  do  not  allow  simultaneous  executions.)  From  these  have  been  calculated 
the  number  of  average  functions  which  would  be  able  to  be  acted  on  concurrently. 
The  next  step  was  to  establish  the  relative  wall  times  of  the  functions  running 
on  the  different  systems  by  again  evaluating  the  statistics  computed  in  A30-3. 
With  these  two  sets  of  figures  the  number  of  functions  completed  per  unit  time 
can  be  easily  determined: 


computer 

RP 

simultaneous 

functions 

wall 

time 

function  per 
unit  time 

1108 

1 

2.19 

1.00 

2.19 

1110  (lxl) 

1.8 

1.92 

.486 

3.95 

1110/40  (2x1) 

3.5 

2.86 

.399 

7.37 

CYBER  175 

6.3 

5.88 

.341 

17.5 

IBM  370/195  or 
CYBER  76 

12.5 

12.5 

.341 

35.3 

The  network  analysis  has  shown  that  in  the  nominal  case  at  most  12  programs 
other  than  the  primary  models  will  be  active  simultaneously  and  in  the  peak 
case  a maximum  of  29  "other  programs"  will  be  active  concurrently.  Using  the 
figures  for  "number  of  functions  completed  per  unit  time" with  these  statistics 
and  rounding  the  resultant  processor  estimates  upward  we  are  left  with  the  pro- 
cessor requirements  expressed  at  the  beginning  of  this  ANALYSIS. 


For  the  primary  analysis  and  forecasting  models  the  nominal  and  peak  numbers 
of  4 and  5 are  used.  Since  the  first  four  computer  sizes  cannot  accomplish  these 
models  in  the  necessary  time  span  no  estimate  of  needed  processors  is  made. 
Furthermore,  since  the  major  models  are  not  yet  in  existence,  only  an  estimate 
of  needed  resources  can  be  made.  For  these  purposes,  estimated  CPU  time  has 
been  used  which  leads  to  the  assumption  that  each  active  model  requires  an 
additional  processor.  As  the  computer  speed  increases,  the  models  will  be 
finishing  faster  causing  less  simultaneous  executes  and  therefore  requiring 
fewer  processors.  In  short,  this  determination  has  been  approximate. 


124 


SUMMARY/CONCLUSION 

To  determine  the  minimum  number  of  a si.igle  size  of  computer  required  to  meet 
GWC's  needs, we  have  broken  down  functional  requirements  into  two  classes: 

1)  those  that  can  be  classed  as  models,  and  2)  all  the  rest.  Each  of  these 
classes  has  then  been  evaluated  separately  since  they  demand  different  computer 
resources.  The  evaluation  from  this  point  is  then  straightforward,  resulting 
ir,  the  numbers  shown  in  the  "Analysis." 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 

^311-1 , 2,  4,  A312-1  , 6,  38,  39,  A121-1  through  3,  A123-1  through  11 
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TRADEOFF  TITLE 


A30-6  Based  on  an  assumed  configuration  mix,  determine  the  number  of  proces- 
sors required  to  meet  the  GWC  workload  by  including  the  factors  of  security 
and  reliability. 

REQU I REMENTS/BACKGROUND 

The  number  of  processor  alternatives  for  this  tradeoff  study  was  narrowed  down 
to  the  five  described  by  consideration  of  the  following  factors: 

a.  The  economics  of  scale  achieved  in  general-purpose  processors; 
also  CPUs  come  in  certain  fixed  sizes,  with  vendors  supplying 
competing  machines  of  comparable  power  (see  Table  3.1). 

b.  Division  of  GWC  processing  into  a general  mix  of  small  jobs  and  a 
small  set  of  numerical  models, 

c.  The  cost  of  software  conversion  in  departing  from  UNIVAC  and 

the  desirability  of  staying  with  the  mainstream  of  the  data  proces- 
sing community,  and 

d.  Homogeneity  of  processors  being  the  least  cost  approach  due  to 
single  operating  system  and  simple  hardware  maintenance;  the 
simplifications  of  network  scheduling;  and  interchangeability  of 
software  among  machines  with  identical  characteristics. 

The  economics  of  scale  and  the  vendor  pricing  policies  create  an  effect  known 
as  "Grosch's  Law"  (see  Table  3.2)  i.e.,  the  price  goes  up  in  proportion  to 
the  square  root  of  the  processing  power.  Therefore,  it  is  advisable  to  choose 
the  minimum  number  of  the  largest  CPUs  available  to  the  extent  that  a 
sufficient  number  of  processors  exist  to  deal  with  the  conflict  problems. 

This  results  in  alternative  B (st^.  Analysis  Table  10.11)  or  8 12  RP  machines. 
Consideration  of  factors  2 and  3 result  in  alternative  A,  a mixture  of  3.5  RP 
and  12  RP  machines.  UNIVAC  can  supply  machines  in  the  3.5  class  (1100/40  2x1 
or  2x2)  but  not  in  the  12  RP  class. 


Table  2.  Processor  Relative  Performance 


roll] 


Average  Relative  Performance 


Uniprocessor  with  maximum  main  memory 
Monthly  Rental  ($000) 


Actual 

Predicted 

1 

40 

40 

2.3 

62 

61 

7.6 

110 

110 

22.6 

186 

190 

Source:  vendor  data  for  IBM  370  product  line. 


1 2 3 4 5 6 7 8 9 10  15  20 

Relative  Performance 

Table  3.  IBM  370  Processor  Performance 
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These  (1100/40  2x2)  can  be  partitioned  by  Network  Control  into  uniprocessors, 
dual  multiprocessors  (or  even  4x4  multiprocessors  if  they  are  properly  con- 
figured) depending  on  the  security  and  processing  constraints  of  the  moment. 

They  were  net  described  as  4x4 s instead  of  two  2x2 s for  several  reasons: 

1.  It  is  very  difficult  to  rank  the  processing  power  of  a 4x4  due  to 

the  lack  of  actual  performance  data.  Since  a 4x4  has  the  same  maximum 
memory  as  a 2x2,  it  may  be  difficult  to  keep  enough  functions  in 
memory  so  that  the  two  additional  CAUs  can  be  utilized.  In  addition, 
the  memory  conflict  will  rise  non  linearly  with  the  number  of  CAUs  . 
These  factors  indicate  that  a 4x4  configuration  is  warranted  only  under 
special  circumstances. 

2.  None  of  the  projected  functions  requires  more  than  a 2x2,  other  than 
the  models,  and  they  will  be  run  on  12  RP  or  faster  machines. 


3.  There  was  an  odd  number  (five)  of  these  machines  required,  so  we  could 
not  have  identical  processors  if  they  were  grouped  as  4x4s  . (It 
would  be  very  unlikely  that  physical  proximity  requirements  could 

be  satisfied  for  using  the  2x2  in  the  variable  perimeter  to  make  up 
a 4x4  in  SX  and  in  normal  access.) 

4.  Security  constraints  are  likely  to  cause  the  system  to  normally  be 
split  into  smaller  units  than  4x4s 

Because  UNIVAC  can  supply  processors  of  the  3.5RP  class,  the  software  conversion 
cost  could  be  zero  for  this  option,  offsetting  the  hardware  price  advantage  of 
the  12RP  class  machines.  Furthermore,  the  12  RP  machines  are  not  in  the  main- 
stream of  vendor  interests.  They  therefore  have  the  drawbacks  associated  with 
owning  a machine  that  is  not  owned  by  very  many  other  people.  For  example,  the 
IBM  195  does  not  run  the  current  operating  system,  VS,  and  IBM  will  not  enhance 
OS  any  further.  Therefore,  the  195  customer  cannot  take  advantage  of  the  tech- 
nological progress  and  supporting  being  given  VS  users. 

By  using  a 3.5-scale  machine  and  an  array  processor,  GWC  will  be  able  to  take 
advantage  of  continuing  vendor  support  and  a large  community  of  users  of  similar 
equipment.  SDC  does  not  intend  that  UNIVAC  1 1 00/40s  be  equated  with  the  3.5  RP 
machines.  The  decision  still  remains  as  to  whether  to  go  competitive  or  not. 
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If  UNIVAC  wins  the  data  base  procurement  then  based  on  software  conversion  costs 
there  may  be  a strong  argument  to  procure  solesource.  Only  the  Air  Force  can 
consider  the  legal  aspects  of  this  decision  and  can  quantify  in  terms  of  cost 
the  advantages  and  disadvantages  of  a sole  source  procurement  and  weigh  the 
balance  against  software  cost  savings.  For  example,  the  IBM  370/168,  AMDAHL 
470,  and  CDC  CYBER  175*  are  also  capable  of  providing  comparable  performance. 

SDC  is  only  suggesting  that  alternative  B be  retained  instead  of  A for  the 
reasons  previously  stated. 


The  homogeneity  of  processors  means  that  they  are  all  from  the  same  vendor, 
have  identical  features  including  memory,  and  can,  therefore,  be  considered 
interchangeable.  This  minimizes  the  cost  of  maintenance  and  simplifies 
network  scheduling.  It  also  minimizes  the  cost  of  redundancy.  When  the 
system  was  split  into  two  categories  (3.5RP  and  others),  we  therefore 
assumed  identical  processors  within  each  category. 


The  Task  1 analysis  indicated  that  five  models  could  be  in  conflict  at  one  time. 
These  models  were  estimated  to  require  a significant  portion  of  a dedicated 
12  RP  class  machine.  One  such  machine  must  also  be  available  for  backup  and 
preventive  maintenance.  Hence,  six  such  machines  would  be  required  by  1982. 
Alternately,  it  should  be  possible  to  augment  the  CPU  power  of  a general 
purpose  machine  with  an  array  processor  or  a parallel  processor.  Because  of 
the  very  fast  logic  and/or  parallel  computation  of  these  machines,  we  should 
never  need  more  than  two  plus  a backup  (options  C&E). 


For  machines  of  the  60  RP  class,  the  requirements  dictated  two  plus  backup 
units.  These  machines  are  generally  used  in  an  R&D  environment  and  do  not 
have  high  ’reliability.  Their  cost  is  also  quite  high,  but  they  were  included 
due  to  GWC  interest  (option  D). 


♦Performance  rankings  for  the  AMDAHL  470  and  CYBER  175  are  based  on  vendor 
engineering  estimates,  rather  than  benchmarks.  They  are  considered  by  SDC 
to  represent  at  least  3.5  RP  machines. 
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DESIGN  APPROACHES/CHARACTERISTICS 

Once  the  kinds  of  processors  involved  in  the  various  configurations  have  been 
determined,  it  remains  only  to  determine  the  number  of  the  various  processors 
needed.  This  is  the  route  taken  in  the  analysis  of  this  problem. 

ANALYSIS 

Results  of  Analysis  on  five  Alternatives: 


a. 

3.5 

RP 

(UNIVAC  1100/40) 

5 

60 

RP 

(ASC) 

5 

(STAR) 

6 

b. 

12 

RP 

(195  or  CYBER  76) 

8 

c. 

3.5 

RP 

(UNIVAC  1100/40) 

5 

12 

RP 

(195  or  CYBER  76) 

6 

d. 

3.5 

RP 

(UNIVAC  1100/40) 

5 

50 

RP 

(any  array) 

4 

e. 

95 

RP 

(STARAN  or  PEPE) 

3 

These  figures  are  based  on  the  following  assumptions: 

1.  The  estimates  made  in  30-5  will  fulfill  the  GWC  requirements 
• providing  reliability  and  security  are  neglected; 

2.  If  at  least  five  processors  of  a given  type  are  available,  then 
no  additional  computers  are  required  for  security  reasons  (the 
security  problem  is  being  considered  minimal  where  the  models 
are  concerned); 

3.  A minimum  reliability  of  .995  is  the  goal. 
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eci f 1c  data  which  have  gone  into  making  the  "decision"  follows 


Individual  Processors  Needed  for: 
Size  Reliability  Production  I Reliabilit 


1100/40 

ASC/Star 

CYBER  76 
or  195 

1100/40 
CYBER  76 
or  195 

1100/40 

array 

1100/40 
STARAN  or 
pepe 


3.5 

60 


.999 
.931/. 7 


5(  .005) 
3( . 1 93) 

7(0.81) 
5(  .005) 

5(0.59) 

5( .005) 
3( .006) 

5( . 005) 


Total 


5( .005) 

(.002) 


5(  .005) 

6(  .002) 

5( . 005) 
3( .006) 

5( .005) 
3(.001) 


Pepe  95  .996  2(.008)  [ 1 | 3(.0Q1) 

The  numbers  in  parentheses  indicate  the  probability  of  failure  (1-reliability) 
for  that  number  and  type  of  processor. 

SUMMARY/CONCLUSION 

Security  has  not  proved  to  be  a factor  in  this  analysis  given  the  relatively 
large  number  of  processors  required  to  accomplish  functions.  Other  than  the 
functions  themselves  the  most  important  point  affecting  the  outcome  of  this 
analysis  has  been  the  reliability  goal  of  .995. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 

A311-1,  2,  4,  A312-1  , 6,  38,  39,  A121-1  through  3,  A123-1  through  11 
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TRADEOFF  TITLE 

A30-7  What  is  the  distribution  of  processing  according  to  the  highest  classi- 
fication absolutely  required? 

REQUIREMENTS/BACKGROUND 

In  order  to  understand  the  total  effect  of  security  problems  on  a configuration 
proposed  for  GWC,  it  is  necessary  to  understand  the  relative  distribution 
of  classification  levels  among  the  various  functions. 


DESIGN  APPROACHES/CHARACTERISTICS 

The  approach  taken  in  this  evaluation  was  to  break  down  all  GWC  functions 
into  the  four  main  areas  defined  in  Task  1:  input  data  processing,  data  base 
and  related  computations,  output  processing,  and  software  processing.  Within 
these  four  principal  regions  the  breakdown  was  then  carried  on,  to  the  type  of 
product  a computation  involved.  Finally  at  this  point  it  became  possible  to 
estimate  the  percentage  of  wall  time  involved  in  the  various  classifications. 

For  our  purposes  here,  only  four  security  levels  were  considered:  Unclassified, 
Confidential,  Secret,  and  Top  Secret. 


ANALYSIS 


Results  of  Study 


Unclassified 
Confidential 
Secret 
Top  Secret 


95% 

<1% 

<1% 

4% 


The  security  mix  indicated  above  is  based  on  percentages  of  wall  time  spent  in 
different  classification  levels.  Those  figures  are  based  on  the  following 
breakdown  of  functional  areas: 


' 
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- input  data  processing  - 

space  environmental  data 

87%U 

3%C 

4%S 

6%TS 

conventional  data 

100%U 

met  sat/imagery  data 

100%U 

product  requests 

75%U 

4%C 

8%S 

13%TS 

digital  radar 

100%U 

special  projects 

25%U 

75%TS 

- data  base  & related  computations 

- 

SESS  computations 

100%U 

request  processing 

50%U 

10%C 

15*S 

25%TS 

analysis  computations 

100%U 

forecast  computations 

100%U 

special  projects 

25%U 

75%TS 

- output  processing  - 

SESS  products 

87%U 

3%C 

4%S 

6%TS 

facsimile  products 

100%U 

satellite/ imagery  related 

100%U 

AWN  products 

100%U 

special  projects 

25%U 

75%TS 

- support  processing  - 

software  development  & 

maintenance 

100%U 

SUMMARY/CONCLUSION 

It  has  been  shown  that  the  majority  of  computer  wall  time  is  spent  on  Unclassi- 
fied function  (95%),  with  4%  Top  Secret,  and  the  remaining  1%  Confidential 
and  Secret. 
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RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 


i 


100  - Special  Activities  - All 
200  - Command  Control  Systems  - All 
300  - Emergency  Was  Order  Support  - All 
500  - Space  Environment  Support  - All 


RELATED  SPECIFICATIONS 


sppwm* 


TRADEOFF  TITLE 

A30-8  Should  we  utilize  a single-array  processor  or  try  to  split  up  the 
problem  to  be  accomplished  on  several  processors? 


REQUIREMENTS/BACKGROUND 

This  question  addresses  the  possibility  of  taking  a function  suited  for  an 
array  processor  and  breaking  it  up  so  that  it  could  be  solved  in  parallel  on 
several  conventional  type  processors. 


DESIGN  APPROACHFS/CHARACTERISTICS 


Utilizing  the  technology  of  tightly  coupled  multiprocessors,  one  still  only 

gets  about  85%  efficiency  out  of  two  computers  that  can  be  obtained  from  one 

the  same  size.  This  is  misleading  of  course  to  the  extent  that  the  parallelism 

afforded  in  side-by-side  processors  presents  a slightly  more  simple  network 

control  problem.  (For  example,  based  on  the  time  of  arrival  of  a job  you 

cannot  necesarily  get  the  two  jobs  done  as  early  on  a single  processor  with 

twice  the  power  as  you  can  on  two  processors  without  splitting  the  jobs.)  / 


ANALYSIS 

The  variables  in  this  problem  seem  to  be  in  inefficiency  resulting  from  split- 
ting a problem  up,  the  ability  of  the  network  control  computer  to  efficiently 
schedule  two  or  more  jobs,  the  size  and  distribution  of  the  jobs,  the  effi- 
ciency of  the  computer  in  terms  of  wait  time  and  I/O  compute  overlap,  the 
number  of  jobs  that  can  actually  be  run  on  the  computer  (i.e.,  its  versatility), 
and  coordination  between  processors. 


SUMMARY/CONCLUSION 

This  question  comes  down  to  a detailed  evaluation  of  any  particular  function 
in  question.  It  must  be  studied  with  each  of  the  points  discussed  under 
"Analysis"  examined  before  a decision  can  be  made. 
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RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements 


601  - General  - Growth 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


M 


SPP 


PHP^BUliP 


A30-9  Should  we  specify  special  array,  parallel,  or  associative  processors 
for  models? 

REQUIREMENTS/BACKGROUND 

An  investigation  of  the  nature  and  functions  of  the  major  AFGWC  models  indicates 
that  they  tend  to  saturate  some  capabilities  of  conventional  computers  without 
approaching  full  utilization  of  others,  and  that  unconventional  computers  might 
be  more  effectively  employed  to  operate  these  models.  The  question  is,  which 
of  three  general  classes  of  computers  is  most  appropriate,  assuming  that  a 
mix  of  unconventional  computers  is  undesirable. 

DESIGN  APPROACHES/CHARACTERISTICS 


Array  processors  are  best  suited  to  programs  which  apply  essentially  the  same 
algorithm  to  many  similar  sets  of  data,  with  little  or  no  crosstalk  between 
the  data  sets.  However,  they  require  a host  computer  to  supply  the  array  of 
data  sets  and  a list  of  instructions  for  the  elements  of  the  array.  Parallel 
processor  systems  can  be  effectively  employed  in  two  ways:  to  allow  more 

than  one  algorithm  to  be  applied  concurrently  to  a single  block  of  data  when 
no  conflicts  or  inconsistencies  can  occur;  and,  to  perform  two  or  more  independent 
tasks  which  involve  distinct  data.  Associative  processors  are  best  employed 
in  situations  in  which  the  data  are  not  well-ordered  (i.e.,  addressable)  for 
the  algorithm  being  executed,  and  reordering  is  impractical  or  unfeasible. 


ANALYSIS 

All  of  the  major  AFGWC  models  operate  on  data  which  are  prearranged  according 
to  geographical  grids.  Since  the  models  perform  essentially  the  same  function 
for  many  or  all  points  of  a grid,  they  are  most  amenable  to  array  processing. 

Normally,  not  all  of  the  data  associated  with  a grid  are  brought  into  main 

memory  for  execution  of  a model;  instead,  selected  fields  are  extracted  from 

the  data  base  which  resides  in  auxiliary  storage,  and  processing  is  then 

performed  with  the  obtained  data  through  relatively  simple  construction  of 

addresses  based  on  the  geographic  grid  structure.  (The  data  base  structuring  , j 
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and  accessing  programs  may  lend  themselves  to  operation  on  associative  processors 
but  this  is  not  the  question  being  addressed.)  Parallel  processors  could  also 
be  usefully  employed  in  operation  of  models,  but  would  not  have  the  impact  on 
execution  time  that  could  be  achieved  with  array  processing.  Typical  grids  are 
29x35  and  larger,  and,  while  parallel  processors  could  substantially  reduce 
running  time  in  comparison  with  simplex  processing,  even  small-array  processors 
(e.g.,  20x20)  could  greatly  increase  model  performance.  Associative  processors 
could  not  be  used  to  advantage  for  model  operation,  since  the  data  addressing 
is  relatively  straightforward,  and  it  is  computing  power  that  is  needed. 

SUMMARY/CONCLUSION 

Of  the  three  classes  of  unconventional  computers,  array  processors  offer  the 
greatest  potential  for  superior  performance  of  model  operation,  and  should  be 
specified  as  a part  of  the  AF6WC  system  for  this  purpose. 

RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements 
No  requirements. 

RELATED  SPECIFICATIONS 


A121-1,  A123-1  through  11,  A311-2,  4,  A312-1  through  39,  A264-2 
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TRADEOFF  TITLE 


A30-10  What  is  the  tradeoff  between  using  separate  processors  for  special 
functions  or  part  of  a large  processor? 

REQUIREMENTS/BACKGROUND 

The  type  of  operations  or  special  functions  which  might  be  candidates  for  this 
consideration  include  communication,  peripheral,  data  base,  and  satellite  data. 

DESIGN  APPROACHES/CHARACTERISTICS 
Factors  which  should  be  considered  include: 

a.  homogeneity  tradeoff, 

b.  availability  of  existing  software  support, 

c.  cost  tradeoff  (specially  designed  processor  versus  fraction  of  large 
processor),  and 

d.  Undesirability  of  mixing  vendors  (i.e.,  interface  problem). 


ANALYSIS 

The  most  serious  argument  for  homogeneity  is  avoiding  the  redundancy.  A 
simple  example  is  that  if  a 10%  redundancy  is  required  to  meet  the  relia- 
bility requirements  and  there  are  10  computers  required,  then  one  extra  is 
required  for  redundancy.  If  there  are  two  different  brands  of  computers, 
five  of  each,  then  two  computers  are  required  for  redundancy.  Homogeneity 
car?  save  the  10%  in  cost  under  that  circumstance.  It  gets  even  worse  if 
you  consider  three  or  four  brands  of  computers. 

SUMMARY/CONCLUSION 

As  far  as  possible,  we  should  avoid  dedicating  processors  to  specialized 
functions.  It  is  more  cost  effective  to  dedicate  part  of  a large  computer  to 
such  a function.  This  conclusion  does  not  conflict  with  that  of  A33-2. 
Obviously  separate  processors  are  called  for  to  handle  some  special  functions. 
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TRADEOFF  TITLE 

A30-11  What  is  the  tradeoff  between  splitting  up  large  jobs  versus  more 
computer  power? 

REQU I REMENTS/BACKGROUND 

The  requirement  challenged  by  this  tradeoff  is  time*  what  approaches  can 
be  taken  that  will  ensure  a large  function  is  completed  in  time? 


DESIGN  APPROACHES/CHARACTERISTICS 

There  are  basically  two  opposing  approaches  to  this  problem: 

a.  the  first  involves  some  amount  of  software  development  and  entails 
splitting  up  a large  function  into  smaller  components. 

b.  the  second  involves  acquiring  more  computer  power  to  ensure  that 
the  function  can  be  completed  in  its  large  complicated  state. 


ANALYSIS 


Splitting  up  large  jobs  usually  is  not  difficult.  Whenever  you  split  up  a 
program  between  two  separate  runs  or  two  separate  machines,  it  does  involve 
documenting  a detailed  interface  at  the  split  and  in  the  case  of  two  different 
machines  providing  for  recoupling  through  the  data  base.  A further  consideration 
is  time  since  one  may  not  have  control  over  when  these  two  portions  are  run 
with  respect  to  one  another,  or  in  some  cases  not  even  the  sequence.  This  is 
where  a well-designed  network  control  option  can  be  of  value.  The  actual 
computer  power  saved  depends  upon  the  number  of  conflicts  which  can  be  deleted 
by  better  flexibility  in  scheduling. 


SUMMARY  CONCLUSION 


Whenever  possible,  large  jobs  should  be  split  up  into  smaller  components  to 
meet  time  requirements  and  save  computer  power. 
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TRADEOFF  TITLE 


A31-1  Can  multiprocessors  exist  under  the  security  requirements? 


REQUIREMENTS/BACKGROUND 


Multiprocessors  run  in  their  multiprocessing  configuration  must  be  at  the  same 
data  path  level.  The  question  becomes:  If  they  are  run  as  multiprocessors, 

can  they  be  run  at  different  levels? 


DESIGN  APPROACHES/CHARACTERISTICS 
(see  ANALYSIS). 

ANALYSIS 

They  can  be  run  at  different  levels  under  the  conditions  that  they  do  not  reside 
as  part  of  common  data  paths  (i.e.,  they  cannot  chare  the  same  main  memory,  disk 
memory,  or  channels  to  other  components).  Further,  they  must  be  physically 
isolated  in  the  same  sense  as  other  components,  where  a switch  can  make  them 
independent  of  one  another  and  protect  against  inadvertent  passage  of  data.  The 
specifications  for  this  distinction  must  be  strict. 

SUMMARY/CONCLUSION 


With  enough  care  and  preplanning,  multiprocessors  can  be  run  at  different 
security  levels. 


RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements 

100  - Special  Activities  - All 
200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 
601  - General  - Growth 


RELATED  SPECIFICATIONS 


A311-2,  4,  8,  A264-2  through  4 
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TRADEOFF  TITLE 


A31-2  Should  data  base  management  be  accomplished  on  a single  machine  or 
should  it  be  a time-shared  function  on  several  machines? 


REQUIREMENTS/ BACKGROUND 


The  job  of  data  base  management  Is  expected  to  become  more  complicated  and 
sophisticated  in  the  future.  It  will  be  a major  specialized  function, 
should  be  decided  whether  it  is  better  to  dedicate  it  to  a particular 
processor  or  allocated  it  as  a time-shared  function  on  several  machines. 


DESIGN  APPRQMHFS/CHARACTERISTICS 


Because  of  the  desire  to  minimize  I/O  time  where  computation  is  not  simultaneously 
being  performed,  it  is  important  to  minimize  data  access  and  wait  time.  The 
problem  with  interjecting  a separate  processor  is  that  the  time  is  great  o 
receive  the  input,  perform  the  necessary  computations,  access  the  data  and  then 
make  the  communications  link  with  the  original  requester.  If  this  time  de  ay 
were  increased  due  to  the  interjection  of  the  network  control  function  which 
would  determine  which  processor  was  to  do  the  job  and  schedule  it,  this  would 
be  a handicap.  However,  the  real  question  is  the  tradeoff  between  that  opera- 
tion versus  the  handling  of  multiple  requests  by  a single  computer  dedicated 

to  the  function. 


ANALYSIS 

This  is  a tough  decision.and  the  tradeoff  is  neither  obvious  nor  presently 
provable.  He  strongly  suspect  that  action  on  a single  machine  would  be 
faster  in  this  instance.  The  other  consideration  is  the  design  prob  em  o 
multiprocessors  accessing  a single  data  base  simultaneously.  He  feel  this 
would  result  in  wait  time  whereas  the  activities  of  the  single  processor, 
although  not  necessarily  faster,  would  be  more  efficient  in  terms  of  wait 
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SUMMARY/CONCLUSION 

Because  of  the  design  problems  we  recommend  that  Centralized  Data  Base 
Management  be  dedicated  to  a specific  processor. 


This  Trade  Study  is  related  to  the  following  requirements 
No  requirements. 


RELATED  SPECIFICATIONS 
A132-1  through  6,  A341-3,  7 


TRADEOFF  TITLE 


A31-3  Can  we  link  an  array  processor  (AP)  to  more  than  one  host? 

* 

REQUIREMENTS/BACKGROUND 

Array  processor  usage  should  be  optimized  due  to  the  expense  ($500,000 
apiece).  Hence,  consideration  should  be  given  to  the  possibility  of  sharing 
array  processors  between  hosts. 

DESIGN  APPROACHES/CHARACTERISTICS 

Sharing  an  array  processor  (AP)  between  to  hosts  requires  that  the  following 
conditions  be  met: 

a.  The  hosts  coordinate  their  usage  of  the  AP. 

b.  The  array  processor  be  within  cabling  contraint  distance  of  both  hosts. 

c.  The  overhead  of  multiplexing  the  AP  between  hosts  is  insignificant. 

d.  The  number  of  hosts  must  be  greater  than  the  number  of  AP's  required 
for  meeting  reliability  and  scheduling  constraints. 

e.  In  addition  to  the  above,  the  AP  must  be  sufficiently  fast  that  several 
hosts  are  required  if  it  is  to  be  kept  busy.  _ 


ANALYSIS 

The  analysis  is  broken  into  a discussion  of  each  of  the  conditions  listed  under 
Desi gn  Approaches/Characteri sti cs : 

a.  Coordination  of  two  CPUs  requires  a shared  memory  where  the  queue 
of  AP  activities  can  be  kept,  or  a high-speed  connection  where  hosts 
can  update  tables  kept  on  each  other's  memory  devices.  For  the 
latter  to  work,  one  host  must  have  precedence  in  its  requests  and 
this  must  be  known  to  both  hosts.  As  will  be  seen  in  the  following 
discussion,  this  is  the  only  condition  that  can  be  met  with  certainty 
at  AFGWC. 
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The  AP  must  be  hung  on  a memory  bus  of  the  host  to  prevent  a host  to 
AP  bottleneck.  This  constrains  APs  to  be  within  about  12  feet  of 
cable  from  the  host.  Hence,  it  is  unlikely  that  hosts  can  share  APs 
due  to  the  very  close  proximity  required  of  the  hosts. 

The  APs  must  be  flexible  devices  to  allow  the  highest  probability 
of  success  in  meeting  future  (not  completely  defined  or  analyzed) 
requirements.  Thus,  they  are  specified  as  being  controlled  by  a 
loadable  microstore.  The  write  time  of  the  microstore  is  far  slower 
than  the  read  time,  hence  the  overhead  of  changing  routines  in  the 
AP  can  be  very  significant.  Therefore  the  hosts  that  share  the  AP 
would  have  to  be  solving  problems  that  require  identical  microcode 
in  the  AP.  This  is  not  likely  and  certainly  cannot  be  guaranteed. 

Each  host  must  have  its  own  AP  to  meet  reliability  and  scheduling 
requirements.  That  is,  if  a processor  system  is  taken  for  PM,  its 
role  must  be  assumed  by  some  other  processor  system.  Role  switching 
may  also  occur  due  to  unscheduled  downtime.  Thus,  each  processor 
system  must  be  prepared  to  run  numerical  models  on  an  AP. 

Since  cabling  constraints  are  tight  (see  b)  for  AP, 

this  means  that  each  processor  system  must  have  its  own  AP. 

The  APs  specified  by  SDC  are  capable  of  autonomous  operation 
to  a great  extent.  They  have  large  local  memories  for  manipulating 
intermediate  results.  Further,  they  can  overlap  their  computations 
with  those  of  the  host.  It  is  unlikely,  therefore,  that  during  a 
numerical  model,  they  would  be  waiting  on  the  host. 


SUMMARY/CQNCLUSIQN 

Each  processor  system  should  have  its  own  dedicated  AP. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 
601  - General  - Growth 


RELATED  SPECIFICATIONS 

A312-1  through  3,  A312-5  through  13 
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TRADEOFF  TITLE 


A31-4  Can  network  control  and  central  data  base  management  have  their  bullpen 
backup  residing  on  the  same  multiprocessor  as  the  primary  function? 

REQUIREMENT/BACKGROUND 

Both  necwork  control  and  central  data  base  management  are  functions  which 
must  have  an  extremely  high  degree  of  reliability  and  a ready  backup  to  assume 
capabilities  in  the  event  of  a failure.  This  is  because  the  entire  data  system 
is  dependent  upon  the  control  and  management  provided  by  these  two  functions. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  bullpen  backup  can  reside  in  two  places.  First,  the  backup  could  be  on  the 
second  half  of  a multiprocessor  (in  effect  we  could  trust  the  reliability  of  a 
multiprocessing  system  to  be  high  enough  as  to  approach  unity).  Second,  we  can 
place  the  bullpen  backup  on  a separate  multiprocessor  system.  Third,  we  can 
force  the  systems  running  network  control  and  central  data  base  management  to 
be  partitioned  into  uniprocessors. 

ANALYSIS 

Having  central  data  base  management  and  network  control  reside  with  their  backup 
on  a multiprocessor,  that  is  trusting  the  multiprocessor  to  be  absolutely 
reliable,  is  very  convenient  from  the  standpoint  that  it  simplifies  switching 
of  peripherals  and  that  is  simplifies  overall  network  scheduling.  Moving  the 
backup  to  a separate  multiprocessor  system  complicates  network  scheduling 
because  both  network  control  and  central  data  base  management  are  very  high 
priority  functions.  Hence,  we  do  not  want  to  place  functions  which  will  require 
high  priority  or  real-time  responses,  or  which  are  very  compute-bound  and  must 
finish  within  a certain  tight  deadline,  on  those  two  processor  systems  unless 
absolutely  necessary.  Therefore,  if  we  make  their  backup  a separate  system  we 
either  incur  the  liability  that  the  primary  may  fail  while  the  backup  is  running 
a high  priority  job,  or  we  severely  constrain  scheduling.  Also  the  bullpen 
backup  is  a warm  backup  and  requires  a program  to  be  loaded  and  ready  in  memory. 
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Hence,  the  backup  system  does  not  have  as  much  memory  available  to  it  for  other 
functions  as  would  be  normally  desirable. 


Forcing  a processor  system  to  run  as  two  separate  uniprocessors  has  several 
disadvantages.  First,  a multiprocessor  can  share  peripherals  more  efficiently. 
Finally,  there  are  many  errors  that  a multiprocessing  system  can  recover  from 
that  uniprocessors  cannot.  However,  most  of  the  errors  that  cause  processors 
to  fail  are  those  which  would  cause  the  multiprocessor  to  fail  as  well  as  the 
uniprocessor.  To  be  more  specific,  the  errors  that  most  often  cause  the  proces- 
sing system  to  fail  are  those  which  are  the  result  of  software  failures  within 
the  executive.  In  this  case,  the  result  is  usually  a deadlock  which  forces  an 
operator  to  reinitialize  the  system.  Secondly,  hardware  failures  within  a 
processor  system  are  normally  the  result  of  memory  failures.  Such  memory  failures 
can  happen  to  either  the  region  in  which  a problem  program  is  operating  or  the 
region  in  which  the  executive  is  operating.  If  it's  the  problem  that  fails,  it 
could  be  either  an  unimportant  program  or  it  could  be  the  software  for  central 
data  base  management.  If  it's  in  the  executive  region,  the  executive  will 
probably  not  be  able  to  recover  from  the  failure. 

SUMMARY/CONCLUSION 


In  summary  there  is  no  clear-cut  way  to  go.  The  best  option  appears  to  be  to 
specify  an  extremely  high  hardware  and  software  reliability  for  both  network 
control  and  central  data  base  management,  backed  up  by  having  the  bullpen 
processor  separate  from  the  processing  system  that  is  running  the  primary 
function.  The  backup  copy  ov  the  program  could  be  kept  in  a roll-out  status 
until  it  is  required  to  become  active.  This  would  minimize  the  impact  on  memory 
of  having  the  backup  function  on  a separate  computer. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

601  - General  - Growth 


RELATED  SPECIFICATIONS 


A341-7 
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TRADEOFF  TITLE 


A31-5  Should  mini  processors  be  used  for  tasks  like  printer  interface,  console 
interface,  and  communications  interface? 

REQUIREMENTS/BACKGROUND 

Printer,  console,  and  comm  interface  are  among  the  type  of  activities  which  can 
be  easily  adapted  to  mini  processors.  This  option  should  be  considered  as  an 
alternative  to  relegating  such  functions  to  the  large  mainframe  computers. 

DESIGN  APPROACHES/CHARACTERISTICS 
(see  ANALYSIS) 

ANALYSIS 

Large  computers  which  are  heavily  involved  in  computation  cannot  efficiently 
be  employed  in  servicing  a multitude  of  peripheral  devices  which  require  little 
computation  but  frequent  attention.  Such  a load  imposes  significant  task 
switching  overhead  on  the  computer  and  temporarily  deactivates  processor  capa- 
bilities which  are  not  applicable  to  peripheral  service.  The  relatively  low 
cost  of  mini  processors  which  can  perform  such  services  makes  them  an  attractive 
and  appropriate  alternative  to  use  of  the  large  computers.  Not  only  can  off- 
loading of  service  functions  to  minicomputers  provide  for  more  effective  use 
of  large  computers,  it  can  result  in  better  performance  of  the  system.  This 
results  from  the  ability  to  code  the  mini1  processors  to  deal  with  the  special 
requirements  of  individual  peripherals  without  concern  for  tying  up  the  signi- 
ficant resources  of  the  large  computers.  Thus,  functions  such  as  device  poll- 
ing, blocking,  and  immediate  response  to  interactive  user  terminals  can  easily 
be  provided  to  the  extent  required.  Additional  functions  such  as  text  editing, 
calculation,  and  memory  aids  may  also  be  provided  to  interactive  users. 





SUMMARY/CONCLUSION 
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There  are  some  functions  which  should  be  dedicated  to  mi n i processors,  specifically 

interface  with  communications  lines,  control  of  consoles  and  routine  of  control 
only  and  upgrade  data. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 
All  requirements. 

RELATED  SPECIFICATIONS 


A122-2,  3,  A313-1  through  17 


TRADEOFF  TITLE 


tJitt 


A31-6  Should  there  be  several  processors  for  communications  or  a single  one? 


REQUIREMENTS/BACKGROUND 

Capacity  and  capability  are  not  the  principal  processor  requirements  for  com- 
munications processing.  The  primary  factors  to  be  considered  are  security 
constraints  and  reliability  demands. 


DESIGN  APPROACHES/CHARACTERISTICS 

Transmissions  into  and  out  of  the  AFGWC  are  classified  as  Top  Secret,  Secret, 
and  Unclassified.  In  order  to  isolate  the  Secret  and  Top  Secret  messages  and 
eliminate  the  possibility  of  inadvertant  crosstalk  which  would  violate  security, 
each  class  of  transmission  should  be  identified  and  directed  through  a pro- 
cessor which  is  assigned  exclusively  to  the  appropriate  classification  level. 

The  reliability  requirement  dictates  a redundant  capability  for  communications 
processing  which  ensures  no  loss  of  critical  data  and  minimal  loss  of  noncriti- 
cal  data;  i.e.,  at  least  two  processors  are  needed,  with  either  able  to  assume 
the  entire  communications  processing  function. 


ANALYSIS 


The  security  requirement  implies  at  least  three  communications  processors  for 
meaningful  isolation.  Full  redundancy  is  not  required  at  all  security  levels 
since  the  planned  system  includes  the  capability  for  switching  processors  into 
different  configurations,  with  automatic  "cleaning"  as  required  for  downgrading 
between  security  levels.  This  process  is  estimated  to  require  on  the  order  of 
10  to  30  seconds,  and  would  enable  one  or  at  most  two  processors  to  back  up  the 
complement  of  three  processors  needed  to  meet  the  security  demands  of  AFGWC 
communications. 


SUMMARY/CONCLUSIONS 

A minimum  of  four  processors  should  be  assigned  to  handle  AFGWC  communication 


functions. 
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TRADEOFF  TITLE 


A32-1  What  programmer  support  software  should  be  provided  (e.g.,  interactive 
programming  language)? 

REQUIREMENTS/BACKGROUND 

Many  software  tools  are  available  to  aid  the  programmer  in  the  development  and 
maintenance  of  his  programs.  GWC's  special  problems  require  a special  look  at 
these  tools. 

DESIGN  APPROACHES/CHARACTERISTICS 

Special  software  which  applies  to  a special  application  such  as  the  software 
required  to  structure  and  access  the  AFGWC  central  data  base  is  not  considered 
support  software  for  the  purpose  of  this  discussion  but  is  classed  with  the 
applications  and  operating  system  software.  Interactive  text  editing  capabili- 
ties, interactive  HOL  compilers  with  multiple  levels  of  compilation  and  analy- 
ses, and  the  capability  to  embed  debugging  statements  which  can  be  optionally 
included  in  the  object  program  represent  the  basic  set  of  tools  required  for 
software  development  in  a facility  which  has  interactive  consoles  for  program 
development.  The  automated  configuration  management  tools  discussed  below 
(see  ANALYSIS)  represent  a minimum  capability  required  to  provide  logistics 
type  support  for  the  software  development  programmer  and  control  to  the  soft- 
ware development  manager. 

Other  more  sophisticated  software  development  tools  are  available  ranging  from 
programs  which  read  a FORTRAN  program  and  make  suggestions  regarding  testing 
procedures  to  System  Simulation-Construction  tools  which  support  the  transition 
of  functionally  simulated  systems  to  real  time  systems  with  constant  visibility 
and  feedback.  Based  on  estimates  of  the  utilization  of  such  tools,  the  cost 
of  such  tools,  and  the  meteorologist-prograimer  rotation,  investment  in  these 
more  sophisticated,  more  complicated  tools  is  not  merited. 

ANALYSIS 

The  support  software  capabilities  listed  below  represent  a basic  set  of  soft- 
ware tools  appropriate  for  the  efficient  development  of  applications  software 
at  the  AFGWC  facility  by  a large  cross  section  of  programmers  attached  to  it. 


156 


Support  software  which  should  be  provided  at  AF6WC  includes: 

1.  An  interactive  text  editing  capability  which  can  be  used  to  update 
either  program  character  stream  or  text  used  for  documentation  pur- 
poses. 

2.  Automated  configuration  management  tools  which  provide  for: 

a)  Update  of  computer  programs  such  that  each  version  (mod)  of  a pro- 
gram is  retained  and  can  be  retrieved  until  deliberate  actions  are 
taken  by  the  file  owner  to  purge  the  version. 

b)  An  audit  trail  of  program  modifications. 

c)  Both  testing  and  operational  versions  of  all  programs  under  configu- 
ration management.  Changes  would  be  allowed  in  testing  versions. 
Changes  would  not  be  allowed  in  operational  versions.  Operational 
versions  of  a given  program  would  enter  the  system  or  replace  older 
versions  only  by  directive  of  the  configuration  manager. 

3.  An  interactive  compilation  capability  where  the  compiler  options  would 
range  from  a capability  for  highly  interactive  entry  of  new  code  aug- 
mented by  language  primer  information  printouts  to  an  option  to  com- 
pile an  optimized  version  of  a program. 

4.  A capability  to  embed  debugging  statements  in  a source  program  such 
that  they  can  be  optionally  compiled  as  part  of  the  object  program  or 
treated  as  comments  or  stripped  out  of  program.  This  capability  could 
be  provided  by  a preprocessing  program  if  the  compiler(s)  available  does 
not  provide  it. 

SUMMARY/CONCLUSION 

There  are  specific  programmer  support  software  tools  which  are  applicable  to 

GWC's  problems  and  environment. 
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RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements 
602  - General -Manpower  Productivity 


RELATED  SPECIFICATIONS 


A331-1  through  18,  A528-1  through  12 


TRADEOFF  TITLE 

A32-2  Should  we  look  at  higher  order  languages  (e.g.,  analysis)? 


REQUIREMENTS/BACKGROUND 


GWC's  special  problems  and  projects  may  benefit  from  the  use  of  higher  order 
languages  tailored  to  specific  needs. 


DESIGN  APPROACHES/CHARACTERISTICS 
(see  ANALYSIS) 


ANALYSIS 

We  recommend  that  a language  translator  with  a macrostatement  capability  be 
considered  for  the  evolutionary  development  of  languages  to  support  activities 
such  as  analysis,  report  generation,  query/response,  etc.  The  translator 
should  permit  development  of  libraries  of  macro  definitions  whiph  can  be 
employed  by  users  either  to  accomplish  a desired  effect,  or  to  construct  other 
macros.  Users  should  be  able  to  design  macrostatements  to  suit  their  purposes 
and  to  have  the  use  of  such  macros  be  translated  either  into  FORTRAN  (or  some 
other  general  programming  language)  for  compilation,  or  into  a conversational 
language  which  can  be  interpreted  in  real  time. 

SUMMARY/CONCLUSION 

Because  of  the  cost  savings  possible  this  should  remain  as  a desiqn  option. 
RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


A32-3  What  is  the  tradeoff  between  dedicating  a function  to  a processor  and 
batched  processing  on  several  (i.e.,  consider  system  utilizations  switching 
and  program  availability)? 

REQUIREMENTS/BACKGROUND 

Requirements  are  dictating  a configuration  of  several  medium-sized  mainframes. 

It  must  be  determined  whether  it  is  more  feasible  to  use  these  machines  by 
dedicating  a function  to  a given  one  or  letting  it  float  around  and  be  pro- 
cessed on  several  (batched)  as  the  other  processors  have  resources  available. 

DESIGN  APPROACHES/CHARACTERISTICS 

Batched  processing  is  best  for  an  optimum  utilization  of  resources.  As  was 
discussed  earlier  in  the  network  control  section,  a significant  amount  of 
resources  saved  by  having  the  flexibility  to  use  the  resource  for  many  differ- 
ent jobs.  Since  the  network  control  system  will  exist,  are  there  any  instances 
in  which  batched  processing  should  not  be  used? 

ANALYSIS 

The  control  function  (set  up  for  purposes  of  resource  scheduling  and  status) 
should  be  applied  at  a single  point  within  the  system.  Also,  from  a security 
standpoint,  it  is  important  that  one  point  be  responsible  for  the  allocation 
of  tasks  according  to  security  level  and  to  understand  what  the  security  status 
of  the  system  is.  Other  areas  where  dedicated  processing  might  be  required 
instead  of  batched  processing  include  those  where  a program  is  used  so  many 
times  that  running  the  program  in  and  out  of  memory  ends  up  being  a burden  on 
the  system.  Two  examples  of  this  are  the  data  base  manager  and  communications 
processing.  Communication  processing  depends  upon  an  analysis  of  the  line 
rates  ana  the  variability  of  the  communications  processing  function  based  on 
different  lines  and  different  messages  types.  The  final  reason  is  speed.  It 
is  important  that  the  network  control  function  operate  fast  enough  so  that  prob- 
lems of  queueing  resources  and  not  dedicating  a computer  in  real-time  does  not  prevent 
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the  requirement  from  being  met.  It  is  thought  that  if  we  set  a design  goal  of 
5 seconds  to  respond  to  high-priority  short  turnaround  tasks,  that  this  is 
attainable  and  will  prevent  the  dedication  of  any  computers  to  the  real-time 
processing  of  data. 

SUMMARY/CONCLUSION 

No  general  statement  can  be  made.  Some  functions  require  their  dedication  to 
a single  processor  but  for  most  others  batched  processing  on  several  processors  is 
adequate. 

RELATED  REQUIREMENTS 

This  Trade  Study  <s  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 

A214-1,  A251-1,  A311-10,  A342-1  through  10,  A641-1,  2?  A71-l?  A813-1  through  22, 
A451-13,  A331-7,  A451-13,  A511-7,  A513-1,  A52^4 
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4.0  TERMINAL  INTERFACE 


(page  164  blank) 


TRADEOFF  TITLE 


A40-1:  What  is  the  splitup  of  functions  between  the  communications  system, 
communications  computer  and  main  processor? 

REQUIREMENTS/BACKGROUND 

Areas  of  responsibility  between  AFGWC  and  AFCS  (1911  Comm.  Sq.)  must  be  clearly 
defined. 

DESIGN  APPROACHES/CHARACTERISTICS 
OPTION  I: 

Each  communication  line  coming  into  GWC  is  terminated  in  a modem  or  other 
device  such  as  the  Data  Link  Terminals  (DLTs)  for  Autodin.  Each  of  these  then 
is  connected  to  the  communications  computer.  The  communications  computer  is 
responsible  for  the  following:  a)  line  protocol  and  maintaining  communications 

over  each  of  the  lines;  b)  formatting  the  message  headers  and  messages  so  as  to 
comply  with  the  line  protocol  for  the  appropriate  communications  link;  c)  iden- 
tification of  incoming  messages  as  to  security  level  and  message  type;  d)  assign- 
ment of  priority  in  establishing  a queue  within  each  priority  level;  e)  message 
recognition/validation,  such  as  start  of  message  and  end  of  message  flags; 
f)  store  and  forward. 

The  main  processor  will  be  responsible  for  the  following:  a)  interface  with 

main  memories  and  mass  memory;  b)  message  decoding/correcting;  c)  message  and 
message  group  validation;  d)  routing  of  messages  internally  within  GWC;  e)  ini- 
tiation of  processors  and/or  notification  of  network  control. 

The  communications  console  is  a vital  element  of  this  structure.  It  must  inter- 
face both  with  the  communications  computer  as  well  as  with  the  main  pro- 
cessors in  order  to  receive  and  validate  incorrect  and  garbled  messages,  both 
incoming  and  outgoing. 
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OPTION  II: 


Unclassified  input  information  handled  by  the  unclassified  communications 
lines  passes  directly  into  an  interface  box-  Network  control  then  determines 
which  main  computer  will  process  this  unclassified  data.  Outgoing  data  for 
the  unclassified  lines  will  follow  the  reverse  path. 

Information  received  over  a classified  line  will  first  encounter  a decoder/ 
router.  This  equipment  will  determine  the  security  classification  and  route 
it  to  the  appropriately  classified  interface  box.  Network  Control  will  deter- 
mine which  computer  receives  and  processes  the  data  so  that  it  remains  in  an 
appropriately  classified  path.  For  Autodin  II,  it  is  assumed  that  the  Data- 
net  355  operations  will  include  the  decoder/router  functions.  Outgoing  data 
will  be  switched  to  the  appropriate  classified  line. 

ANALYSIS 
(see  above) 

SUHMARY/CONCLUSIONS 

The  1911th  Communications  Squadron  will  be  responsible  for  the  communi- 
cations system,  the  decoder  router,  and  the  communications  computer,  if 
it  is  a separate  mini.  GWC  will  be  responsible  for  the  disk  interface 
device  (if  not  the  mini),  the  disk,  the  main  processor  and  the  communi- 
cation console.  This  is  documented  in  Tradeoff  Study  A40-2. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 


RELATED  SPECIFICATIONS 


A811-12 
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TRADEOFF  TITLE 

A40-2:  i What  is  the  division  of  responsibility  between  the  1911th  Communica- 
tions Squadron  (AFCS)  and  GWC? 

REQUIREMENTS/BACKGROUND 

With  the  current  system,  the  division  of  responsibility  between  AFCS  and  GWC 
has  been  difficult  to  define  because  System  I acts  as  both  a communications 
processor  and  a data  processor.  The  division  of  responsibility  needs  to  be 
clearly  delineated. 

DESIGN  APPROACHES/ CHARACTERISTICS 

The  line  or  separation  between  the  two  organizations  hinges  upon  the  decision 
relative  to  the  necessity  to  have  mini-computers  or  only  interface  devices. 
Since  the  Decoder/Routers  can  handle  the  basic  comnuni cations  functions,  the 
mini -computers  are  not  required. 

ANALYSIS 

The  1911th  Communications  Squadron  will  be  responsible  for  the  communications 
system  and  the  Decoder/Router.  GWC  will  be  responsible  for  the  disk  interface 
device,  the  disk,  the  main  processor,  and  the  comnuni cations  console. 

The  interface  between  the  communications  subsystem  and  GWC  should  be  jointly 
agreed  upon  and  published  by  the  1911th  and  GWC.  Some  of  the  types  of  infor- 
mation to  be  specified  in  this  document  are  as  follows:  a)  a method  of  data 
transfer  with  an  acknowledgement/non-acknowledgement  system;  b)  the  size  and 

format  of  the  data  buffers  to  be  handed  back  and  forth;  c)  flags,  routing  bits 
and  similar  details. 

SUMMARY/CONCLUSIONS 

With  this  division,  the  1911th  Communications  Squadron  will  have  responsibility 
for  equipment  and  circuit  performance,  as  well  as  operating  the  communications 
system.  GWC  will  be  responsible  for  data  processing. 
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TRADEOFF  TITLE 


A40-3:  Determine  the  cost  savings  and  security  impact  in  using  RTOS  in  a 

classified  machine  only  as  a router  of  lower-level  messages  to  a lower-level 
configuration. 

REQUIREMENTS/BACKGROUND 

This  is  a Univac  proposal  in  which  a Univac  processor  similar  to  the  current 

System  I would  be  utilized  partly  as  a communications  processor  and  would  be 
established  in  a secure  area. 


DESIGN  APPROACHES/CHARACTERISTICS 

All  communications,  both  classified  and  unclassified,  would  enter  into  this 
communications  processor.  RTOS  would  be  used  to  separate  the  classified  from 
the  unclassified  information  and  the  unclassified  would  be  handled  by  MAXISC 
and  passed  on  to  System  II.  The  classified  information  would  remain  in  this 
new  front-end  system  and  would  be  processed  there.  This  would  imply  a one- 
way transfer  of  data  base  information  to  the  classified  computer  for  process- 
ing of  the  classified  information,  similar  to  what  is  now  done  in  the  current 
System  III.  Although  this  separates  the  security  problem  into  two  areas  so 
that  there  are  two  levels  of  classification,  it  still  does  not  eliminate  the 
problems  of  mixing  different  classified  levels;  that  is,  confidential,  secret, 

and  top  secret  information.  Thus,  the  system  would  still  be  subject  to 
security  violations. 


ANALYSIS 

In  order  to  determine  the  cost  of  this  alternative,  the  following  assumptions 
were  made.  The  front  processor  would  be  a 1 X 1 1100/40  which  equates  to 
API. 9.  Based  upon  the  estimate  that  30%  of  the  current  System  I is  utilized 
solely  for  communications  purposes,  this  would  equate  to  16%  of  an  1100/40. 
The  price  of  an  1100/40  is  approximately  3 million  dollars:  thus,  16%  of  the 
3 million  dollars  is  $480,000.  Because  there  would  be  very  little  change  fro. 

e software  utilized  in  the  current  System  I,  it  is  estimated  that  two  man 
months  at  $4,000  per  man  month  would  be  required  for  software  development. 
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This  brings  the  total  cost  to  $488,000.  However,  in  order  to  provide 
reliability  necessary  for  this  system,  a 1 for  1 backup  in  hardware  would  be 
required.  Thus,  this  is  another  $480,000  bringing  the  total  required  for 
this  option  to  $968,000. 

The  other  alternative  is  to  utilize  small  computers  for  the  communications 
functions.  To  accomplish  this,  it  would  require  four  new  minicomputers.  The 
SADPR-85  study  accomplished  by  ESD  estimated  the  cost  for  a large  front  end 
processor  system  to  be  approximately  $85,000  in  1977.  However,  based  upon 
current  information,  it  is  felt  that  a more  appropriate  number  is  approxi- 
mately $150,000  for  a front  end  processor  system. 

Thus,  the  hardware  costs  for  the  four  minicomputers  would  be  $600,000.  In 
addition,  there  would  be  a requirement  for  software  development,  estimated  at 
aprpoximately  10  man  years  for  a total  of  $480,000.  Added  to  this  is  the 
requirement  for  backup  to  the  main  processors  in  order  to  provide  the  necessary 
reliability.  This  would  be  accomplished  with  two  additional  processors  at  a 
cost  of  $300,000.  Thus,  the  total  cost  for  this  alternative  would  be 
$1,380,000. 
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SUMMARY/CONCLUSIONS 

Although  the  cost  of  the  option  using  several  small  processors  is  over 
$400,000  more  than  the  option  utilizing  one  large  processor,  it  does  offer 
the  advantage  of  complete  separation  of  the  different  levels  of  classification 
and  therefore  greatly  reduces  the  chance  of  any  security  violations.  The 
selected  option  is  thus  to  utilize  the  mini -computers  for  the  communications 

functions. 

It  should  be  noted  that  neither  of  the  above  options  include  the  hardware  or 
software  costs  associated  with  the  Datanet  355  processor  for  Autodin  II  or  the 
Interdata  Model  50  processors  associated  with  the  Weather  Facsimile  Switching 

Center. 
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RELATED  REQUIREMENfTS 

This  Trade  Study  is  related  to  the  following  requirements: 

113  - Special  Activities  - Program  D 
120  - Special  Activities  -•  ZOOM  Use 
200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 
602  - General  - Mnapower  Productivity 

RELATED  SPECIFICATIONS 
A451-1  through  A451-22 
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TRADEOFF  TITLE 


A40-4  Should  message  logging  be  employed? 


REQUIREMENTS/BACKGROUND 

Message  logging  would  provide  a list  of  all  messages  received  and  transmitted, 
the  security  classification  of  each  message,  and  the  date  and  time  of  receipt 
or  transmittal. 


DESIGN  APPROACHES/CHARACTERISTICS 


Logging  could  be  accomplished  either  by  a large  processor  or  by  a small 
communications  processor. 


) 


ANALYSIS 

— 

This  would  prove  very  valuable  in  the  quality  control  function  by  helping 
improve  response  time  of  incoming  conmuni cations  and  by  improving  internal 
GWC  procedures.  Message  logging,  however,  would  increase  the  software 
development  and  the  software  overhead,  as  well  as  increase  the  requirement 
for  data  files  in  the  mass  storage  associated  with  the  communications 
processors. 

j 

SUMMARY/CQNCLUSIQNS 

The  value  of  message  logging  should  outweigh  the  increased  cost  of  software 
and  mass  storage. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 


TRADEOFF  TITLE 

A40-5  Should  query/response  intei races  be  standardized? 
REQUIREMENTS/BACKGROUND  # 

The  future  requirements  for  GWC  will  demand  a vastly  increased  query/response 
capability.  This  is  true  not  only  in  quantity  but  also  in  the  shorter  time 
requirements  associated  with  the  requests.  In  addition,  a much  larger  group 
of  users  will  have  access  to  the  automated  response- to-query  data  base. 
Primarily,  this  will  be  through  Autodin  II  and  the  WWMCCS  net. 

DESIGN  APPROACHES/CHARACTERISTICS 
Not  applicable. 

ANALYSIS 

A wide  variety  of  information  can  be  requested  by  users,  primarily  requests 
for  computer  flight  plans.  Thus,  it  is  imperative  that  the  query/response 
interface  be  standardized. 

SUMMARY/CONCLUSIONS 

In  order  to  limit  the  impact  of  this  large  requirement,  GWC  should  establish 
and  publish  library  request  codes.  These  codes  will  be  limited  to  the  minimum 
number  to  satisfy  the  specific  requirements  of  the  users.  Requests  for 
similar  information  can  thus  be  standardized  and  limit  the  impact  on  both 
the  hardware  and  software.  This  should  be  similar  to  the  GWC  product  manual 
and  detail  the  codes  to  be  used  for  specific  information  to  be  derived  from 
the  data  base. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 

RELATED  SPECIFICATIONS 
A41-1,  2,  4,  12,  13 


TRADEOFF  TITLE 


A40-6  What  maximum  rates  should  be  considered? 

REQUIREMENTS/BACKGROUND 

Input  and  output  data  rates  for  different  users  vary  widely.  Each  communica- 
tions link  has  a specified  data  rate. 

DESIGN  APPROACHES/CHARACTERISTICS 

For  most  of  the  input  and  output  data  from  GWC,  the  data  rate  is  quite  low  and 
could  easily  be  handled  on  lines  up  to  a 4800  baud  capacity.  However,  there 
are  certain  future  requirements  that  will  require  a much  higher  data  rate. 
These  are  a 50  kilobaud  capacity  for  Autodin  II,  a 50  kilobaud  capacity  for 
passing  satellite  data  to  the  Navy  Fleet  Numerical  Center,  and  a 200  kilobaud 
capacity  for  inputting  digital  radar  data. 

ANALYSIS 

Existing  lines  handle  the  GWC  data  very  effectively.  Therefore,  the  only  data 
rates  that  need  to  be  considered  are  the  new  requirements. 

SUMMARY/CONCLUSIONS 

The  system  will  accommodate  line  rates  of  4800  baud  with  the  following 
exceptions : 

AUTODIN  II  50  kilobaud 

Satellite  data  to  FNWC  50  kilobaud 

Digital  Radar  200  kilobaud 
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RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

200  - Command  Control  Systems  - All 

300  - Emergency  War  Order  Support  - All 

401  - Environmental  Support  - Fleet  Weather  Central 

410  - Environmental  Support  - Digital  Radar 

RELATED  SPECIFICATIONS 
A411-1,  A422-2,  A425-1 
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TRADEOFF  TITLE 


A40-7  What  approach  should  be  taken  to  editing  and  checking  of  outgoing 
messages? 

REQUIREMENTS/BACKGROUND 

Editing  and  checking  of  the  weather  data  is  extremely  important  because  the 
users  are  demanding  more  accuracy. 

DESIGN  APPROACHES/CHARACTERISTICS 

Coding  and  decoding  of  the  weather  information  is  an  internal  GWC  function. 
Therefore,  the  terminal  interface  is  not  involved. 

ANALYSIS 
None  required. 

SUMMARY/ CONCLUSIONS 

Coding  and  decoding  of  messages  will  be  accomplished  in  the  main  processors. 
Editing  and  checking  of  the  contents  of  messages  will  be  the  primary  respon- 
sibility of  the  console  operators,  as  well  as  of  the  main  processors.  When 
these  messages  are  handed  to  the  communications  processor,  they  will  be 
validated  as  to  format  prior  to  being  logged  and  transmitted. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 
A40-9,  10,  A514-9 
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TRADEOFR  TITLE 


A42-1  how  will  SWI  data  be  handled  in  the  proposed  architecture? 
REQUIREl^ENTS/BACKGROUND 

Within  the  special  access  perimeter,  three  generic  security  compartments 
exist.  Precedence  has  not  totally  dictated  separation  of  these  compartments. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  approach  which  can  be  taken  is  to  rely  on  software  to  maintain  the 
integrity  of  these  compartments  as  is  done  in  the  current  System  3 environment 
with  respect  to  other  compartmental ization.  The  design  can  be  accomplished 
to  provide  protection  similar  to  the  protection  of  Secret  from  Confidential 
data  and  other  hierarchical  security  separation  accomplished  in  the  normal 
access  perimeter. 

ANALYSIS 

The  number  of  unique  processors  required  within  the  AFGWC  system  is  a function 
of  the  number  of  conflicts  that  can  exist  simultaneously.  We  have  further 
confined  the  problem  by  indicating  that  processors  can  only  reside  at  a 
special  access  or  a normal  access  level.  The  distribution  of  jobs  is  such 
that  many  more  jobs  occur  at  the  normal  access  level  thereby  allowing  us  to 
allocate  many  more  processors  to  that  level  and  thus  provide  more  flexibility. 

The  fact  that,  under  the  normal  operating  conditions  only  a single  dual 
processor  will  exist  within  the  special  access  perimeter,  less  flexibility  is 
provided.  We  therefore  have  a strong  desire  for  homogeniety  of  computer  types 
across  the  whole  system  to  minimize  the  cost  in  providing  backup  for  reliability. 

Under  these  constraints  theoretically  the  ratio  of  number  of  jobs  to  be  run 
in  the  special  access  area  to  those  run  in  the  normal  access  area  should  be 
equal  to  the  ratio  of  number  of  processors  allocated  to  each  of  these  areas. 

Even  considering  noncompartmental ization  in  the  special  access  area  this 
assumption  is  not  quite  true  since  we  feel  that  job  load  in  special  access 
area  actually  is  less  than  would  be  required  for  the  computing  power.  The 


two  computers  are  required  there  mainly  because  one  is  required  as  reliability 
backup  to  the  other. 

If  smaller  processors  were  specified  we  could  reallocate  the  ratio  thereby 
properly  approximating  the  job  load.  The  specification  of  a smaller  computer 
however  is  not  consistent  with  what  we  feel  will  be  available  and  most 
competitive  from  the  various  vendors  in  a procurement. 

Further  compartmentalization  within  the  special  access  area  even  makes 
matters  worse  if  it  is  felt  that  due  to  conflict  three  distinct  processors 
must  be  continually  available  to  the  automatic  allocation  of  the  network  control 
process.  However,  based  on  our  analysis  of  AFGWC  requirements,  we  feel  that 
we  can  safely  make  the  assumption  that  the  availability  of  two  distinct 
processors  within  the  special  access  area  and  the  additional  ability  to 
reconfigure  the  variable  perimeter  into  special  access  status  through  manual 
switching  provides  adequate  responsiveness  to  meet  a three  compartmented  demand. 

SUMMARY/CQNCLUSIONS 

SDC  recommends  that  the  three  distinct  security  levels  within  the  special 
access  area  be  treated  as  follows:  Two  compartments  exist  distinct  but  parallel 

within  the  hierarchical  structure  and  they  are  both  subordinate  to  the  highest 
classification  level  afforded  a special  access  area.  The  data  bases  shall 
remain  distinct  and  the  processors  shall  be  allocated  to  the  appropriate 
classification  level  with  the  ability  to  upgrade  data  to  the  highest  level,  if 
required.  Through  switching,  a variable  perimeter  computer  can  be  brought 
in  to  accommodate  conflicts  of  up  to  4 programs  which  can  be  run  simul- 
taneously through  network  control  manual  switching.  Forecaster  consoles  can 
be  dedicated  to  any  one  of  the  levels  through  manual  switching.  The  entire 
data  base  within  the  normal  access  perimeter  (with  the  exception  of  TSSIOP) 
is  available  for  processing  any  of  the  jobs  in  the  special  access  perimeter. 


The  capability  for  a higher  level  classification  data  base  to  overlay  the 
meteorological  data  base  exists  at  any  one  of  the  three  levels.  The  capability 
also  exists  to  output  data  resulting  from  computation  and  through  the  security 
monitor  to  downgrade  certify  a lower  level  of  classification  to  be  sent  to 
the  appropriate  level  in  any  of  the  normal  access  comnuni cation  systems. 
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RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements 
No  Requirements. 


RELATED  SPECIFICAT I ONS 


TRADEOFF  TITLE 


( 


A43-1  Should  the  option  and  capability  exist  to  prefilter  satellite  data  based 
on  data  base-defined  and/or  user  time  criteria? 

REQUIREMENTS/BACKGROUND 

In  the  satellite  data  processing  area,  it  is  advantageous  to  reduce  the  total 
system  resources  needed  to  fulfill  the  satellite  image  processing  at  AFGWC. 

Higher  selectivity  in  processing  the  satellite  data  would  provide  a resource 
reduction. 

DESIGN  APPROACHES/CHARACTERISTICS 

SDC  feels  that  due  to  the  selectivity  used  in  meteorological  sensor  data 
gathering  operations,  the  recorded  sensor  data  will  never  have  an  exact  con- 
formation and  content  required  by  the  user.  If  the  data  do  not  furnish  an 
explicit  user  data  requirement  or  aid  in  the  realistic  needs  of  general 
global  forecasting,  they  could  and  should  be  filtered  out  of  the  automated 
processing  function.  This  function  can  be  performed  by  software  just  prior 
or  simultaneous  to  raw  data  gridding  and  mapping. 

ANALYSIS 

Currently  6.53  wall  hours  (Uni vac  1110  2 x 1)  are  utilized  to  grid  and  map 
DMSP  visual  and  infrared  data.  This  time  factor  is  expected  to  ramain  constant  into 
the  Blc/ck  5D  area.  TIROS-N  will  require  similar  system  resources  for  a 
total  of  13.06  wall  hours  (excluding  fine  data  processing  time).  We  suspect 
that  elimination  of  excessive  coverage  in  the  high  latitude  polar  regions 
alone  could  eliminate  ten  percent  or  1.3  wall  hours  of  gridding  and  mapping 
processing.  We  further  suspect  that  judicial  and  conscientious  filtering 
could  eliminate  as  much  as  thirty  percent  of  the  gridding  and  mapping  time 
or  3.9  wall  hours. 
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SUMMARY/CONCLUSIONS 

To  optimize  the  use  of  computer  resources  for  satellite  data  processing, 
options  should  be  avail#)le  to  permit  prefiltering  of  satellite  data,  using 
data  base-defined  and/or  user  time  criteria. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 


100  - Special  Activities  - All 

208  - Command  Control  Systems  - TAC 

300  - Emergency  War  Order  Support  - All 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


A43-2  Should  the  Satellite  Image  Dissemination  Subsystem  (SIDS)  interface  be 
a minicomputer,  normal  handling  of  tapes,  or  a direct  interface  with 
the  mapping  and  gridding  function  (input  and  output)? 

REQU IREMENTS/BACKGROUND 

AFGWC  currently  provides  several  satellite  imagery  products  to  external 
customers.  The  techniques  now  utilized  for  that  dissemination  are  inadequate 
for  the  future  customer  needs  and  data  volumes.  AWS  has  presented  a plan  for 
that  distribution;  the  plan  was  generated  based  on  current  AFGWC  system 
architecture  and  in  our  opinion  does  not  lend  itself  to  growth  indicated  by 
the  Task  1 requirements  analysis. 


DESIGN  APPROACHES/CHARACTERISTICS 

The  following  options  are  candidates  for  the  imagery  distribution  system: 

Option  A - Manual  operation  as  presented  in  the  AWS/SID  plan,  1974. 

Option  B - Semi  Automated  System  which  would  receive  inputs  from  manual 
visual  products  and  computer  reconstituted  products,  the 
latter  transferred  to  the  SID  over  remote  tape  devices. 

Option  C - Automated  System  driven  by  minicomputer.  Data  would  still  be 
received  from  manual  sources  but  would  be  held  to  a minimum. 
Most  products  would  be  reconstituted  by  the  Satellite  Image 
Generation  Subsystem  (SIGS)  and  transferred  directly  to  the 
SIDS  minicomputer. 


ANALYSIS 


Option  A Cost 


24  hour  manning  for  three  operators  is  estimated  to  be  $300K  per  year  (one 
scheduler  and  two  operators).  For  the  1977  - 1982  time  frame,  this  will 
amount  to  $1.8  for  manning.  Hardware  costs  (excluding  the  communications 
equipment)  are  estimated  at  $1 00K. 

Total  approx.  $1.90M 
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Option  B Cost 


24  hour  manning  for  2.5  operators  (one  scheduler  and  1.5  operators)  is 
estimated  at  $250K  per  year.  For  the  1977  - 1982  time  frame  this  will  total 
$1 . 5M  for  manning.  Hardware  costs  (excluding  the  communications  equipment) 
are  estimated  at  $1 50K. 


Total  approx. 


$1.65M 


Option  C Cost 

24  hour  manning  for  one  operator  is  estimated  to  be  $ 1 00K  per  year,  For  the 
1977  - 1982  time  frame,  this  will  be  $600K  for  manning.  Hardware  costs 
(excluding  communications  equipment)  will  be  $300K  plus  $200K  software 
development  cost  and  $10K  per  year  software  maintenance  costs. 


Total  approx. 


$1.1 6M 


SUMMARY/CONCLUSIONS 


Option  A and  B are  deemed  to  be  too  costly  due  to  manpower,  requiri ng  several 
operators  per  shift. 

Option  C is  retained;  once  programmed,  this  will  provide  a system  that  will 
require  one  operator  per  shift.  Manual  inputs  will  be  input  via  laser  scanner 
to  mass  storage.  Reconstituted  inputs  will  be  transferred  from  the  SI6S 
existing  in  a main  processor.  The  mini  will  also  be  the  scheduler 
of  product  output  and  control  output  protocol,  all  requiring  minimum  operator 
control.  The  system  will  easily  handle  increased  phaseover  to  a higher 
percent  of  reconstituted  products  as  available. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 
A444-1 , A515-1 


TRADEOFF  TITLE 


A43-3  Should  the  capability  exist  to  interface  raw  ungridded  data  with  the 
SID  interface? 

REQUIREMENTS/BACKGROUND 

AFGWC  must  distribute  satellite  imagery  products  in  a timely  and  accurate 
manner.  This  will  be  accomplished  by  the  Satellite  Image  Dissemination 
Subsystem  (SIDS). 

DESIGN  APPROACHES/CHARACTERISTICS 

Option  A - Interface  SIDS  to  the  raw  data  storage 

Option  B - Provide  SIDS  with  gridded  imagery  produced  by  the  vehicle 
dedicated  interface  subsystem  (Site  III,  DUS,  etc.)  and 
computer  reconstituted  imagery. 


ANALYSIS 

Reasons  for  discarding  Option  A. 

a.  Programning  costs  to  develop  software  to:  (1)  selectively  retrieve 

data  from  the  raw  data  files,  and  (2)  reconstitute  imagery; 

b.  Information  available  on  raw  data  files  will  be  available  in  gridded 
form  within  minutes  of  its  availability  on  raw  storage;  and 

c.  All  imagery  to  meet  requirements  can  be  supplied  by  option  B. 
SUMMARY/CONCLUSIONS 

Option  A is  discarded.  SIDS  will  utilize  option  B,  Option  B provides  products 
primarily  in  the  form  of  imagery  products  reconstituted  from  the  gridded  satellite 
data  bases,  supplemented  by  gridded  data  from  the  vehicle  dedicated  interface 
subsystem.  As  AFGWC  expands  the  gridded  satellite  data  bases  phase-over  to  more 
reconstituted  products  will  occur. 
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RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements: 

120  - Special  Activities  - ZOOM  Use 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 

A43-4  Should  satellite  data  be  gridded  and  mapped  on-the-fly  utilizing  array 
processors  or  should  the  processing  continue  to  utilize  current 
techniques  and  an  upgraded  central  system  processing  with  buffering? 


REQUIREMENTS/BACKGROUND 

A major  problem  facing  AFGWC  during  the  1 977- 1 982  time  frame  is  the  ingestion 
gridding  and  mapping  of  DMSP,  TIROS-N  and  GOES  satellite  data.  Currently, 
AFGWC  grids  and  maps  the  HR  and  IR  2nm  data  available  from  DMSP.  During  the 
1977-1982  period  DMSP  data  will  be  available  at  1.5nm  (smoothed)  and  .3(fine) 
nm  resolution.  Similar  data  will  be  available  from  TIROS-N  in  1978.  GOES 
data  will  also  be  available  in  1976. 

This  tradeoff  is  based  on  the  following  requirements  provided  to  SDC  on  guide 
lines  in  this  study: 

a.  Total  processing  of  all  DMSP  and  TIROS-N  smoothed  data. 

b.  Three  percent  processing  of  DMSP  fine  data  in  1978  and  ten  percent 
in  1980. 

c.  The  processing  of  five  (20°  x 20°)  windows  of  GOES  data  in  1977. 

The  daily  data  volume  associated  with  these  requirements  are: 

DMSP  (2  vehicles) 

Smoothed  266  x 10^  words/day 
Fine  data  23.94  x 10^  words/day  (1978) 

Fine  data  79.8  x 10^  words/day  (1980) 

TIROS-N 

Smoothed  266  x 10^  words/day 
Fine  data  (not  required) 

GOES 

42  readouts  2142  x 10^  words/day 
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DESIGN  APPROACHES/CHARACTERISTICS 

Two  options  to  be  evaluated  are  on-the-fly  gridding  and  mapping  utilizing  array 
processors  and  buffered  griddinq  and  mapping  utilizing  central  system 
processors.  The  tradeoffs  dealing  with  the  array  processor  in  the  buffered 
approach  are  quite  similar  to  those  presented  for  the  on-the-fly  array  except 
the  buffered  array  cost  would  have  to  additionally  reflect  ttu?  storage  costs. 
Both  concepts  are  fully  compatible  with  the  remainder  of  the  system 
architecture. 

ANALYSIS 

Acquisition  costs  for  an  on-the-fly  system  capable  of  handling  simultaneous 
inputs  for  the  three  satellite  programs  are  as  follows: 


Array  processing 

DMSP 

TIROS-N 

GOES 


2 ea.  at  .5M 
1 ea.  at  .5M 


1 ea.  at  .5M 


Software  Development 

DMSP  n 
TIROS-N  .5f 
GOES  . 5f" 


Integration,  Engineering,  Interfacing  Hardware 

TOTAL 

Acquisition  Costs  for  Enhanced  Buffered  System 


$5  million 


Preprocessor 

Hardware 

Software 

Mass  Storage 


2 at  250K  ea. 
250K  ea. 


10  disk  (Uni vac  8433)  36K  ea. 

2 controllers  TOOK  ea. 


m 
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Integration,  Engineering  and  Interfacing  Hardware  $500K 

TOTAL  $1 .81  million 

NOTE:  Approximately  $236K  of  this  equipment  is  currently  in  inventory 
at  AFGWC. 

The  following  are  time  estimates  for  gridding  and  mapping  on  the  Univac  1100 
(2x1): 

a.  3.5  min.  (wall  time)  per  quarter  orbit  for  smoothed  data  mapped  at 
approximately  3nm  resolution 

b.  30  min.  (wall  time)  per  2/5  orbit  for  fine  data  mapped  at  approximately 
.3nm  resolution  (maximum  recorded  data  per  orbit) 

DMSP  GRIDDING  AND  MAPPING  TIME 
Smoothed  Data 

14  revs  • 4 quarter  orbits  per  rev  • 3.5  min  • 2 vehicles  = 

392  min.  per  day 

Fine  Data 

10  revs  • 30  min.  • 2 vehicles  = 170 
1978  three  percent  = 18  min.  per  day 
1980  ten  percent  = 60  min.  per  day 

TIR0S-N  GRIDDING  AND  MAPPING  TIME 
Smoothed  Data 

(Same  as  DMSP)  392  min.  per  day 
GOES  GRIDDING  AND  MAPPING 

42  readouts  per  day  • 11  min  per  readout  = 462  min.  per  day 

Total  gridding  and  mapping  time  for  DMSP,  TIR0S-N  and  GOES  in  1980  (maximum 
requirement)  is  1306  minutes  (Univac  1110  time). 

On-the-fly  gridding  and  mapping  would  require  dedicated  resource  during  ingest. 

The  time  estimates  are  then  based  on  2.5  min.  readout  time  per  smoothed  orbit 
and  10  min.  per  fine  orbit.  Total  dedicated  time  for  TIR0S-N  and  DMSP  is 


DMSP 


X 


1 


(2,5  min  per  orbit  on  the  14  orbits  • 2 vehicles  = 70  in.) 
(10  min.  on  10  orbits  per  day  • 2 vehicles  = 200  min.) 

(3  percent  = 6 min  and  10  percent  = 20  min.) 


The  total  time  to  grid  and  map  fine  data  would  not  add  to  the  time 
since  the  requirement  for  fine  data  are  less  than  the  time  required 
for  smoothed  data. 


TIR0S-N 

2.5  min.  on  14  orbits  per  day  • 2 vehicles  = 70 

GOES 


NOTE: 


5 min.  per  readout  (estimated)  • 42  readouts  per  day  = 420  min.  per 
day 

This  is  the  time  required  to  grid  and  map  GOES  on-the-fly 
and  would  account  for  total  gridding  and  mapping  and  not  just 
the  required  5 (20°  x 20°)  areas.  The  array  would  be 
required  to  perform  continuous  gridding  and  mapping  in 
order  to  extract  the  fine  data  windows. 


Total  on-the-fly  processing  time  = 350  min.  or  5.8  hours. 


Time  estimates  for  GOES  processing  are  not  available  and  these  are  not 
addressed  in  this  tradeoff. 


In  the  enhanced  architecture,  the  central  system  processor  will  have  core  sizes 
sufficiently  large  to  increase  the  number  of  map  boxes  being  mapped  by  a factor 
of  6 to  8.  This  would  enable  the  gridding  and  mapping  system  to  overlap  1/0. 
Currently  approximately  80  percent  of  this  wall  time  is  1/0  wait  time.  It  is 
feasible  that  the  time  required  to  grid  and  map  on  the  enhanced  central  system 
could  be  reduced  to  20  to  30  percent  of  the  run  time  due  to  overlap  of  1/0. 

At  30  percent,  this  would  reduce  the  run  time  to  6,5  hours  compared  to  6.8  run 
time  for  the  on-the-fly  system. 
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SUMMARY/CONCLUSIONS 

The  array  processor  utilized  in  either  the  buffered  approach  or  the  on-the-fly 
approach  does  not  potentially  provide  enough  marginal  speed  increase  to 
warrant  the  expectations  of  an  additional  $3.3M  to  $3.5M.  The  satellite  data 
gridding  and  mapping  should  be  optimized  by  increasing  the  central  system 
processor  storage  capacity  in  order  to  implement  significant  I/O  overlays. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special  Activities  - All 
208  - Command  Control  Systems  - All 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

RELATED  SPECIFICATIONS 
None 
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TRADEOFF  TITLE 

A44-1  What  is  the  tradeoff  between  the  use  of  one  large  communications 
processor  versus  several  small  ones? 


REQUIREMENTS/BACKGROUND 

The  current  system  uses  System  I as  a communications  computer.  This  causes  a 
large  software  overhead  within  the  Real  Time  Operating  System  (RTOS)  and  over- 
loads the  core  memory.  In  addition,  all  security  classifications  except 
special  access  are  operated  upon  in  this  system,  violating  the  security 
separation  requirement.  Security  requirements  dictate  that  there  shall  be 
the  least  possible  mixing  of  levels  of  classification. 
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DESIGN  APPROACHES/CHARACTERISTICS 

One  approach  to  use  two  large  computers  with  revised  software  to  provide  as 
much  security  as  possible.  The  second  approach  is  to  use  small  computers 
as  front  ends  for  the  large  computer  systems,  each  of  them  dedicated  to  a 
security  level. 


ANALYSIS 

If  dedicated  security  level  processors  are  used,  the  quantity  required  is 
based  on  the  number  of  distinct  security  paths.  The  security  paths  are 
special  access,  SWI,  Top  Secret,  and  SPECAT  (which  can  be  treated  as  Secret). 
The  communications  processors  must  be  consistent  with  the  various  levels  of 
messages  which  can  arrive  or  be  originated  at  GWC:  Unclassfied,  Confidential, 

Secret,  Top  Secret,  SWI,  and  Special  Access. 

The  philosophy  followed  in  this  design  is  to  determine  the  classification  of 
message  as  soon  as  possible  in  the  processing  and  to  switch  it  into  the 
appropriate  path  or  if  message  classification  cannot  be  determined,  to 
output  it  on  the  communications  console.  This  reduces  the  mixed  mode 
processing  and  the  exposure  of  one  level  of  classification  to  other  levels  of 
classification  in  the  data  base  and  the  computer  programs.  Doing  this  results 
in  less  chance  for  compromise  due  to  either  hardware  error  or  to  malicious 
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action  through  software.  In  the  same  vein,  output  messages  should  not  be 
switched  to  the  data  line  until  the  last  possible  minute.  The  switching 
function  should  be  independent,  and  should  be  performed  by  an  isolated 
hardware/software  function. 

SUMMARY/CONCLUSIONS 

It  is  not  consistent  to  have  a large  interface  processor  for  communications. 
Instead,  a switch  based  on  initial  security  determination,  and  then  a small 
communication  processor  at  the  level  of  the  path  into  which  the  message  is 
switched,  should  be  employed.  These  small  processors  will  provide  flexibility 
and  classification  level  security. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 

RELATED  SPECIFICATIONS 
A41-5,  6,  9,  11 
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TRADEOFF  TITLE 


( 


A44 


-2  Should  priority  of  message  be  considered  in  processing? 


DESIGN  APPROACHES/CHARACTERISTICS 
(See  ANALYSIS) 


ANALYSIS 


It  is  important  that  the  communications  processor  recognize  the  priority  of 
the  incoming  and  outgoing  messages  so  that  it  can  establish  a queue  within 
each  priority  level.  Communications  processors  should  also  obtain  priority 
interrupts  so  that  the  highest  priority  message  is  operated  on  first. 


SUMMARY/CONCLUSIONS 


The  operating  philosophy  in  the  communications  subsystems  shall  be  a first-in 
first-out  activity  at  each  priority  level. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 
All  requirements. 


RELATED  SPECIFICATIONS 


A41-2 
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REQUIREMENT5/BACKGR0UND 

In  addition  to  various  security  levels  transmitted  over  the  communications 
lines,  messages  of  different  priorities  are  used.  These  consist  of  the  normal 
DOD  priorities;  e.g.,  routine  and  immediate,  as  well  as  time  response 
priorities  established  by  the  users. 
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TRADEOFF  TITLE 

A44-3  What  approach  should  be  taken  to  decode/checking  of  the  incoming  data? 
REQUIREMENTS/BACKGROUND 

Weather  data  received  by  GWC  is  in  the  fom  of  messages  with  the  information 
encoded.  Thus,  the  data  must  be  decoded  and  verified  prior  to  being  usable 
in  the  data  bases. 

DESIGN  APPROACHES/CHARACTERISTICS 

Decoding/ checking  can  be  completely  automated  or  accomplished  by  a man/machine 
combi nati on. 

ANALYSIS 

This  function  is  performed  internal  to  GWC.  When  the  communi cations  console 
receives  an  incoming  message,  it  will  take  the  following  steps  to  check  the 
data:  a)  check  parity,  b)  identify  the  type  of  message,  c)  validate  the  format 

of  the  message,  d)  check  the  priority  prior  to  entering  the  data  into  an  appro- 
priate queue,  e)  check  the  security  level  in  order  to  pass  the  data  along  the 
proper  GWC  security  link. 

Questionable  messages  upon  which  'he  communications  processor  cannot  act  will 
be  passed  to  the  communications  console  for  action;  or  retransmission  will  be 
requested  prior  to  handoff  of  the  data  to  the  GWC  main  processor. 

The  main  processor  then  will  take  the  following  actions  prior  to  processing  the 
data:  a)  decide  which  decoder  is  appropriate,  b)  decode  the  message, 

c)  examine  the  message  text,  and  d)  validate  the  message. 

SUMMARY/CQNCLUSIONS 

Decoding/checking  is  a necessary  function  that  will  be  performed  under  the 
control  of  the  communications  console. 
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RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements 
All  requirements. 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


A44-4  Should  only  headers  be  certified  for  communications  data  or  should  there 
be  more  extensive  message  checking  capabilities? 

REQUIREMENTS/BACKGROUND 

In  communications  interfaces  such  as  AUTODIN,  error  checking  is  relied  on  to 
establish  the  security  level  of  a message.  In  general,  there  is  a man 
injected  in  the  loop,  however,  to  further  certify  proper  classification  of 
the  message.  In  an  automatic  data  system  interface,  a question  arises  as  to 
whether  more  checking  is  warranted. 

DESIGN  APPROACHES/CHARACTERISTICS 

Presently,  only  the  headers  and  the  individual  buffers  or  segments  which  make 
up  messages  are  checked.  The  checking  could  be  expanded  to  further  recognize 
total  message  structure  and  content. 

ANALYSIS 

There  is  not  adequate  standardization  to  allow  checking  for  structure  or 
content  at  the  present  time.  Many  messages  are  manually  originated,  thereby 
imposing  more  rigid  constraints  on  the  message  generator.  The  opportunity 
does  exist  to  standardize  WWMCCS  messages.  However,  this  would  only  be  a 
small  subset  of  the  total  traffic.  According  to  a consensus  of  those  assoc- 
iated with  the  present  system  and  others  investigating  the  problem,  the  checking 
of  communication  headers  and  buffers  is  thought  to  be  adequate  and  the  invention 
of  further  checking  would  be  of  little  improvement  over  the  current  approach. 


SUMMARY/CONCLUSIONS 

SDC  proposes  that  no  additional  checking  be  accomplished. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 
All  requirements. 


RELATED  SPECIFICATIONS 
A41-1 
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TRADEOFF  TITLE 

A44-5  What  processor  configurations  should  be  used  for  the  line  handler/ 
decoder  routers? 

REQUIREMENTS/BACKGROUND 

In  the  architectural  design  there  is  a requirement  for  a line  handler/decoder 
router  computer  which  interfaces  with  all  lines  of  a given  maximum  security 
level.  In  some  instances  the  computers  have  already  been  specified  (for 
example,  the  Data-Net  355  for  AUTODINI I ) . The  functions  to  be  performed  by 
this  computer  include: 

a.  Line-specific  interfaces  which  for  non-intelligent  line  termination 
includes  all  line  protocol  and  synthronization  tasks  and  for  lines 
with  intelligent  terminals  it  includes  prespecified  interfaces. 

b.  System  specific  message  decoding  to  determine  message  security  level 
and  to  ensure  message  begin  and  end  conditions. 

c.  This  processor  must  perform  the  routing  function  which  includes 
selecting  a channel  corresponding  to  the  correct  security  classi- 
fication, authentication  of  the  channel,  gaining  access  to  the 
appropriate  disk  on  which  the  message  is  to  be  written  and  finally 
writing  the  message  onto  the  disk. 


d.  The  line  handler/decoder  router  has  the  task  of  interfacing  with  the 
communications  console.  When  it  recognizes  that  messages  are  to  be 
manually  processed  or  that  security  checking  is  not  satisfactory, 
it  automatically  routes  the  message  to  the  communications  console. 


DESIGN  APPROACHES/CHARACTERISTICS 


Based  on  a)  requirements,  b)  cost,  c)  confusion  in  trying  to  reverse 
current  data  line  interface  decisions;  the  approach  seems  straight  forward. 

That  is,  to  utilize  a mini  computer  which  can  perform  the  functions  specified, 
with  special  consideration  given  to  computers  already  intended  for  use  minimize 
backup  costs  and  achieve  software  development  cost  savings.  The  key  charac- 
teristics in  the  decision  are  the  ability  to  insure  proper  routing  and  the 
ability  to  interface  with  the  disk  subsystem. 


ANALYSIS 

The  options  for  interface  with  the  disk  depend  on  the  controller  selection. 
Assuming  the  use  of  a standard  disk  controller  then  there  must  be  some  way 
for  the  communications  computer  to  know  where  the  data  should  be  written. 

This  can  be  provided  by  the  computer  reading  a file  of  the  disk  which  provides 
this  information  or  it  can  be  provided  by  a natural  cascading  of  files  for 
individual  computer  whereby  the  timing  disallows  the  possibility  of  a 
communications  computer  writing  over  the  unprocessed  data  of  another.  A 
final  solution  is  the  existence  of  a write  lockout  to  the  communications 
buffer  area  which  is  removed  when  the  data  are  processed. 

SUMMARY/CONCLUSIONS 

" \ 

We  feel  that  since  the  specification  of  the  exact  intercommunications  between 
the  line  handler/decoder  router  and  the  classified  disk  depends  on  the 
features  and  capabilities  of  the  disk  subsystem  that  the  specification  should 
be  written  to  reflect  this. 

RELATED  REQUIREMENTS  , 

This  Trade  Study  is  related  to  the  following  requirements: 

All  requirements. 


RELATED  SPECIFICATIONS 


A113-3 


TRADEOFF  TITLE 


A44-6  Should  packet  switching  capability  be  used  for  security/application 
routing? 

REQUIREMENTS/BACKGROUND 

Various  high  speed  switching  techniques  are  being  considered  by  the  Defense 
Communications  Agency  for  use  on  the  Autodin  II  System. 

DESIGN  APPROACHES/ CHARACTERISTICS 

Packet  switching  is  a method  of  making  efficient  use  of  transmission  lines  and 
uses  store  and  forward  techniques.  The  messages  are  subdivided  for  efficiency 
in  transmission  into  short  segments  called  packets  of  about  100  characters  in 
length.  These  packets  are  transmitted  through  multiple  switching  centers  from 
source  to  destination.  At  each  switching  center  or  node,  the  packet  is  stored 
in  core  memory  for  only  a few  milliseconds  and  then  routed  along  dynamically 
determined  paths.  Each  node  maintains  a continuously  updated  routing  table 
so  that  packets  can  be  easily  routed  at  each  switching  center  along  the  path 
which  most  efficiently  minimizes  transmission  delay  at  that  moment.  When  a 
message  is  transmitted  it  is  subdivided  into  packets  and  transmitted  to  the 
destination  along  any  available  network  path.  Each  packet  proceeds  along  its 
own  path  until  it  reaches  its  destination  where  all  packets  are  stored.  The 
complete  message  is  reassembled  for  delivery  to  the  receiving  host  or  terminal. 

ANALYSIS 

The  ARPANET  is  currently  using  this  approach.  The  other  application  of  this 
technique  would  be  in  Autodin  II  which  will  involve  a very  large  network  of 
users  (particularly  the  WWMCCS  net).  In  this  application  the  Datanet  355  will 
act  as  a terminal  interface  processor  and  divide  messages  into  packets  for 
transmission  and  reassemble  received  packets  into  complete  messages.  For 
minimal  handling  of  information  at  the  various  security  levels  that  will  be 
transmitted  through  Autodin,  the  Datanet  355  will  be  connected  directly  into 
the  GWC  system. 
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TRADEOFF  TITLE 


A45-1  To  what  extent  should  protocol  be  standardized? 

REQUIREMENTS/BACKGROUND 

Line  protocol  affects  the  complexity  of  the  software  required  to  operate  on 
the  incoming  messages  and  format  the  outgoing  communications.  In  addition, 
the  multitude  of  external  links  use  different  protocols  which  compound  the 
problem. 

DESIGN  APPROACHES/CHARACTERISTICS 

A standardized  message  protocol  for  all  external  GWC  messages  would  greatly 
simplify  the  communications  software. 

ANALYSIS 

On  all  the  existing  communications  links,  the  protocol  has  already  been  estab- 
lished and  is  in  operation.  Therefore,  little  can  be  done  to  change  it  except 
for  future  possibilities  with  new  requirements.  However,  on  new  systems  such 
as  Autodin  II,  there  is  a possibility  that  GWC  can  influence  protocol  to  be 
established  on  the  line.  This  would  be  particularly  important  with  high  data 
rates  such  as  the  Autodin  II  at  50  kilobaud  and  even  more  so  on  the  digital 
radar  which  is  expected  to  have  data  burst  rate  of  200  kilobaud.  There  is  a 
strong  effect  of  protocol  on  the  software  involved  in  the  communications 
processor.  By  establishing  the  protocol  or  influencing  the  protocol,  GWC 
can  have  a much  simpler  approach  to  software  development. 

SUMMARY/CONCLUSIONS 

GWC  should  take  a very  detailed  look  at  the  protocol  possibilities  available 
with  these  new  systems  and  standardize  wherever  it  is  possible,  then  let  this 
influence  the  older  systems  whenever  changes  are  made  to  those  links. 


RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements 
All  requirements. 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


A46-1  Should  the  interface  with  all  facsimile  systems  be  the  Interdata  50? 
REQUIREMENTS/BACKGROUND 

In  data  automation  requirement  no.  AFCSJ-74-4  dated  1 February  1975,  the  Air 
Force  Communications  Service  has  proposed  a weather  facsimile  switching  center 
(WFSC) . The  purpose  of  the  WFSC  is  to  replace  the  manual  facsimile  operation 
at  GWC  and  enable  the  weather  facsimile  functions  at  the  National  Meteorologi- 
cal Center  at  Suitland,  Maryland  to  be  incorporated  into  the  system  at  the 
AFGWC.  This  will  provide  total  automation  from  a centralized  CONUS  weather 
facsimile  facility. 

DESIGN  APPROACHES/CHARACTERISTICS 

For  automation  of  its  facsimile  operations,  the  National  Weather  Service  is 
currently  employing  an  Interdata  Model  50  minicomputer.  In  order  to  utilize 
this  information  directly,  the  Air  Force  Communications  Service  has  purchased 
their  own  Interdata  Model  50  which  is  located  at  the  National  Meteorological 
Center  at  Suitland,  Maryland.  It  is  currently  being  programmed  by  the  AFCS 
personnel  with  the  assistance  of  the  personnel  from  the  National  Weather 
Service  who  already  have  software  operating.  This  will  provide  complete 
compatibility  between  the  facsimile  transmission  systems  of  both  the  Air  Force 
and  the  National  Weather  Service. 


ANALYSIS 


In  order  to  complete  the  compatibility  and  establish  a centralized  facility  for 
the  Air  Force,  the  Air  Force  Communications  Service  is  proposing  the  purchase 
of  two  Interdata  Model  50s,  to  be  located  at  AFGWC  for  transmission  of  facsimile 
products  throughout  the  Air  Force  networks.  After  the  two  Interdata  Model  50s 
are  installed  and  operating  at  GWC,  the  unit  at  the  National  Meteorological 
Center  will  be  moved  to  Offutt  as  a backup  to  the  two  at  that  facility.  Thus, 
the  Interdata  Model  50  will  be  utilized  for  all  facsimile  transmissions  from 
GWC.  Some  of  these  transmissions  will  be  automated  and  will  be  generated  at 
the  automated  work  centers,  while  others  will  be  manually  prepared  facsimile 
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products  which  will  be  handcarried  to  the  WSFC  for  the  AFCS  personnel  to 
digitize  and  then  transmit  through  the  Interdata  50s. 


SUMMARY/CONCLUSIONS 

Forecaster  consoles  which  produce  facsimile  products  will  be  connected  to  the 
Interdata  50s  which  will  interface  with  all  of  the  facsimile  circuits. 

RELATED  REQUIREflEfITS 

This  Trade  Study  is  related  to  the  following  requirements: 

412  - Environmental  Support  - Weather  Facsimile  Switching  Center 


RELATED  SPECIFICATIONS 
A472-1 


204 


5. 0/6.0  CONSOLES/DATA  INPUT  AND  DISPLAY 


TRADEOFF  TITLE 


A50-1  What  method  should  be  utilized  for  providing  and  updating  information 
to  the  AWCs? 


REQUIREMENTS/BACKGROUND 

The  Automated  Work  Center  (AWC)  processors  must  interface  to  the  main  system 
processors.  The  AWCs  are  divided  into  (a)  those  that  require  a highly 
responsive  interface  and  (b)  those  where  the  response  may  be  delayed  in  the 
seconds  range.  The  AWCs  in  the  first  class  also,  due  to  security  guidelines, 
require  a dedication  to  a particular  system  processor  or  are  connected  to  all 
the  system  processors  in  a parameter.  The  second  class  of  AWC  will  not  require 
system  dedication  because  the  jobs  associated  with  the  work  centers  are 
scheduled  on  various  system  processors. 


DESIGN  APPROACHES/CHARACTERISTICS 


The  direct  interface  AWCs  will  utilize  dedicated  system  processor  I/O  channels. 
The  channels  will  be  connected  via  ICCU-type  devices  and  utilize  normal 
intercomputer  software  interrupt  protocol.  Incompatibility  between  the 
wordlength  of  the  AWC  support  processor  (16,  32,  or  36  bits)  and  the  wordlength 
of  the  system  processor  (32,  36,  or  60  bits)  would  require  special  software 
and/or  hardware  for  format  compatibility.  Switching  for  these  AWCs  will  occur 
infrequently,  normally  once  or  twice  per  day  via  manual  network  control  switches. 


The  indirect  or  mail-drop"  interface  AWCs  will  be  connected  via  multiple- 
accessed  storage  devices  (disks).  The  disks  will  be  multiported  to  the  AWC 
support  processors  and  to  the  system  processors.  Job  requests  from  these 
AWCs  will  be  "mail -dropped"  onto  the  disk  system  and  in  parallel  routed  to 
Network  Control  (NC)  via  one-way  communication  links  that  are  multiplexed  into 
the  NC  processor.  Products  in  response  to  these  requests  will  also  be  "mail- 
dropped"  on  disk  by  the  assigned  or  scheduled  system  processor.  This  "mail-drop" 
will  be  periodically  (approximately  once  per  second)  queried  by  the  AWC 
processors  for  requested  products.  The  products  will  be  retrieved  and 
distributed  to  the  requesting  console  and  stored  on  local  main  storage  devices. 
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ANALYSIS 


Two  major  factors  affect  the  interfacing  of  AWCs  to  system  processors:  (1) 

the  responsiveness  of  the  interface  and  (2)  the  desire  to  maintain  as  much 
flexibility  of  scheduling  system  processors  as  possible.  These  two  factors 
in  the  extreme  cases  are  not  totally  compatible.  That  is,  in  order  to  obtain 
an  extremely  fast  response  the  responding  processor  must  be  directly  tied 
to  the  requestor.  In  this  case  scheduling  would  exist  only  within  the 
dedicated  machine  and  not  between  the  available  system  processors.  If  more 
flexibility  is  desired  it  implies  time  delay;  delay  due  to  scheduling  a 
processor,  allocating  the  job,  and  disk  drop  and  retrieve  (twice). 

The  variability  of  AFGWC  AWC  responsive  requirements  and  task  require  that 
the  interfacing  techniques  not  rely  on  only  one  method.  Therefore  both 
methods  of  interface  will  be  used  at  AFGWC. 

The  following  AWCs  will  require  direct  dedicated  interface  to  at  least  one 
system  processor. 

a.  Network  Control 

b.  Computer  Operation 

c.  Security  Monitor  Output  Stations 

d.  Software  Development  and  Studies/Analysis.  (Note:  the  nature  of 

"off-the-shelf"  software  development  systems  require  dedication 

processors. ) 

The  following  AWCs  will  utilize  the  disk  implemented  "mail -drop"  interface 
technique: 

a.  Forecaster  Consoles 

b.  Special  Operations 

c.  Quality  Assurance 

d.  Remote  Job  Entry 
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SUMMARY/CONCLUSION 

Those  techniques  utilized  to  provide  information  to  the  AWCs  is  based  on 
the  desire  to  provide  a responsive  and  flexible  interface. 

Therefore,  the  methods  chosen  are  (1)  dedicated  communication  paths  to 
AWCs  which  primarily  require  responsiveness  and  (2)  a "mail-drop"  disk 
taumjnkatiuri  terbnique  for  ttot  do  not  require  responsiveness  in 

milliseconds  but  for  which  flexibility  is  desired. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

120  - Special  Activities  - ZOOM  Use 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

RELATED  SPECIFICATIONS 

A20-6,  A313-1  through  17,  A50-1 , 2,  A511-3,  A20-5,  A513-4,  A514-6,  A515-4 
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TRADEOFF  TITLE 

A51-1  What  are  the  tradeoffs  associated  with  a centralized  operations  console 
versus  independent  ones? 

REQUIREMENTS/BACKGROUND 

Operations  consoles  which  survey  and  to  some  extent  control  the  status  of  GWC's 
computer  systems  can  be  placed  as  monitors  for  individual  computers  or  groups 
of  several  of  them.  The  factors  which  will  determine  the  number  and  placement 
of  the  ops  consoles  must  be  determined. 

DESIGN  APPROACHES/CHARACTERISTICS 

This  study  will  consider  two  possible  levels  at  which  ops  consoles  might  be 
placed: 

a.  at  the  level  of  the  individual  computer 

b.  at  the  level  of  the  perimeter  (with  only  special  access  and  normal 
access  perimeters  being  considered) 

ANALYSIS 

Keeping  in  mind  the  precedent  established  by  the  positioning  of  the  Network 
Control  Consoles  solely  in  the  Special  Access  Perimeter,  it  seems  a logical 
next  step  to  place  the  ops  consoles  in  areas  where  they  can  act  as  centralized 
monitors  within  their  perimeters.  This  would  suggest  an  ops  console  in  the 
special-access  perimeter  and  another  in  the  normal-access  perimeter.  Under 
such  a configuration,  the  levels  at  which  console-monitors  exist  include: 
network  control,  operations  consoles,  and  individual  computer  processors. 


This  decision  to  centralize  ops  consoles  is  also  strengthened  by  the  network 
control  principles  which  will  allow  functions  to  float  from  one  computer  to 
another  within  a given  perimeter  as  computer  resources  dictate.  This  means 
that  the  individual  computer  may  not  be  able  to  even  continually  monitor  the 
health  of  one  function,  it  will  take  an  ops  monitor  at  the  perimeter  level  to 
make  that  determination. 
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TRADEOFF  TITLE 


A51-2  Should  we  consider  interactive  satellite  image  compression/rejection  for 
display? 

REQUIREMENTS/BACKGROUND 

The  fully  automated,  consistent,  and  accurate  extraction  of  useful  meteor- 
ological phenomena  from  remotely  sensed  data  is  currently  beyond  the 
state-of-the-art.  In  fact,  criteria  for  automation  have  not  yet  been 
established.  In  the  current  time  frame,  the  remotely  sensed  data  are  presen- 
ted to  the  meteorologist  in  a pictorial  format,  either  on  a CRT  or  more 
commonly  on  photographic/facsimile  hardcopy.  The  existence,  recognition,  and 
identification  of  meteorological  characteristics  containing  useful  informa- 
tion are  manually  performed  by  a perusal  process.  This  process  is  performed 
manually  for  both  static  and  dynamic  (i.e.,  time  dependent)  characteristics. 

In  the  latter,  time-lapsed  sequences  are  prepared  for  perusal  by  a meteor- 
ologist in  either  motion-picture  film  formats  (becoming  rapidly  obsolete)  or 
by  refreshing  a CRT.  The  determination  of  wind  vectors  from  cloud  motions 
derived  from  selected  cloud  locations  in  successive  GOES  data  frames  is  a 
current  technique  exemplifying  the  use  of  time -lapsed  sequences  to  extract 
information  from  dynamic  meteorological  phenomena. 


DESIGN  APPROACHES/CHARACTERISTICS 

The  attainment  of  capabilities  for  fully  automated  extraction  of  useful 
meteorological  information  for  remotely  sensed  data  would  be  a desirable  achieve 
ment.  An  ability  to  automatically  extract  pertinent  meteorological  information 
would  subequently  enable  the  following  cost  conserving  advantages  to  accrue: 


a. 


Reduction  in  the  number  and  talent  level  of  required  meteorological 
operational  personnel  (including  their  training  cycle). 

Minimization  of  computational  growth  requirements  resulting  from 
elimination  of  data  that  do  not  contain  useful  meteorological 
information  (this  activity  is  closely  related  to  efforts  concerned 
with  development  of  data  rejection  algorithms  applied  during  the 
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initial  data-stream  processing.  The  problems  of  data  compression 
are  different  from  those  of  data  rejection). 


c. 


Reduction  of  time  intervals  between  data  input  and  resulting  output 
of  significant  meteorological  information  to  enable  faster  turn- 
around where  meteorological  information  is  perishable  (to  either 
the  end  user  as  a product,  or  as  initial  condition  input  values 
for  exercising  numerical  analysis  or  forecast  models). 


ANALYSIS 


To  achieve  automated  information  extraction  it  is  necessary  to  establish 
quantitative  criteria  and  to  then  invoke  numerical  pattern  recognition  and/or 
signature  analysis  principles,  probably  employing  both  structured  and  non- 
structured  techniques.  A meteorological  (numerical)  filter(s)  would  have  to 
be  developed  for  the  various  types  of  information  to  be  extracted  from  the 
remotely  sensed  data.  This  activity  can  be  significantly  enhanced  by  providing 
a semiautomated  (i.e.,  interactive)  capability  for  the  learning  process.  Once 
the  filter  has  been  established  and  tested,  it  can  be  applied  to  the  opera- 
tional data  stream  to  automatically  extract  the  meteorological  information 
for  which  it  was  designed. 

SUMMARY/CONCLUSIONS 

GWC  should  develop  the  capability  for  interactive  satellite  image  compression/ 
rejection  for  display.  It  may  be  required  to  achieve  automated  meteorological 
information-extraction  capabilities  and  the  associated  long-term  operational 
cost  reduction  advantages. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirments: 


120  - Special  Activities  - ZOOM  Use 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

602  - General  - Manpower  Productivity 


RELATED  SPECIFICATIONS 
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TRADEOFF  TITLE 
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A52-1  What  features  should  exist  in  the  forecast  console? 


REQUIREMENTS/BACKGROUND 

GWC  has  identified  a tentative  plan  for  a computer-assisted,  semiautomated 
METWATCH.  One  goal  of  the  METWATCH  concept  is  to  minimize  the  number  of 
personnel  required  to  manually  prepare  and  format  supporting  information 
required  by  a meteorologist  for  analysis  and  forecasting  activities. 


DESIGN  APPROACHES/CHARACTERISTICS 


The  use  of  interactive  CRT  consoles,  controlled  and  operated  by  a forecaster, 
supported  with  computation  and  display  generation  facilities  has  been  identi- 
fied as  a viable  approach  for  subsequently  minimizing  manual  information  and 
chart/map  preparation  while  simultaneously  enabling  the  forecaster  to  retain 
the  flexibility  required  to  prepare  meteorological  analyses  and  forecasts. 


ANALYSIS 


The  forecaster  will,  under  his  control  option,  observe  selected  data  sets 
presented  on  a CRT(s)  and  accept,  reject,  modify  and/or  combine  the  presented 
information  to  enable  him  to  formulate  a custom- tai lored  data  set  for  meteoro- 
logical analysis  and/or  forecast  for  output  to  the  user.  The  forecaster  will 
have  available  input  devices  such  as  digitizing  tables,  trackball,  and  keyboard 
for  entering  control -and-command  functions  and  for  inputting  data.  A refresh 
memory  will  be  included  as  part  of  the  console  configuration  to  store  data  to 
be  presented  on  CRTs.  Since  satellite  and/or  ground  radar  imagery  and  graphics 
information  are  needed  by  the  forecaster,  the  console  configuration  will 
probably  need  both  raster  and  vector  type  CRTs.  Overlay  capabilities  for 
"wedding"  graphics  to  satellite/radar  information  would  also  be  required. 

This  capability  must  be  supported  with  frame-to- frame  registration  techniques. 


Some  of  the  supporting  operating  capabilities  required  to  enable  the  forecaster 
to  manipulate  the  information  are: 
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Zoom  or  window 

Encode  subset  areas  by  controlling  a cursor 

Pseudo  coloring 

Split  screen 

Roll  frame 

Overlay 

Erase  (selectively) 

Blink 

Trace 

Vary  resolution 
Threshold 

Priority  establishment 

Accessibility  to  a variety  of  data  bases 

SUMMARY/CONCLUSIONS 

The  capability  shall  exist  which  will  allow  the  forecaster  to  observe  selected 
sets  of  data  presented  on  CRT(s)  and  accept,  reject,  modify,  and/or  combine  the 
presented  information  to  enable  him  to  formulate  a custom-tailored  data  set 
for  meteorological  analysis  and/or  forecast  for  output  to  the  user. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 


113  - Special  Activities  - Program  D 

115  - Special  Activities  - Agency  B 

217  - Command  Control  System  - Crisis  Management 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

511  - Space  Environment  Support  - OTHB  Radar 

602  - General  - Manpower  Productivity 


RELATED  SPECIFICATIONS 

A52-2  through  4,  A52-7  through  15,  A52-17  through  19 
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TRADEOFF  TITLE 


A52-2  What  is  the  tradeoff  between  alternative  programmer  interfaces  with  the 
data  system? 


REQUIREMENTS/BACKGROUND 

The  types  of  programmer  interfaces  with  the  data  system  must  be  identified. 
The  advantages  and  drawbacks  of  each  must  be  determined. 


DESIGN  APPROACHES/CHARACTERISTICS 

The  two  kinds  of  programmer  interfaces  considered  in  this  study  are: 


a. 

b. 


remote  run  card  entry  readers 
remote  terminals 


ANALYSIS 


Programmers  can  maintain  their  source  statements  on  cards  kept  in  their  office 
which  are  either  manually  submitted  to  an  operation  desk  or  entered  into  a 
remote-run  entry  card  reader.  SDC  does  not  recommend  this  approach  to  inter- 
facing programmers  with  the  data  system  for  several  reasons: 

a.  Card  decks  are  cumbersome  and  get  lost  or  scrambled,  decreasing 
programmer  productivity. 

b.  Card  handling  requires  additional  operations  personnel. 

c.  A programmer  will  tend  to  keep  only  one  copy  of  a program,  which  he 

will  submit.  Afterwards,  he  cannot  continue  to  work  on  the  program, 

and  must  switch  to  another  one  or  be  idle.  With  online  programming, 
he  can  easily  compile  and  test  changes  to  one  subroutine  while  con- 
tinuing to  work  on  an  extra,  temporary  copy  of  the  code.  He  can  thus 
maintain  his  continuity  of  thought,  and  overlap  his  compilation 

and  test  runs  with  other  work. 

d.  With  programmers  keeping  individual  source  desks,  it  is  nearly 

impossible  to  create  and  maintain  a software  catalog  to  maximize 

reuse  of  existing  routine. 

e.  Interactive  software  development  replaces  the  batch-card  interface. 
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Remote  terminals  are  required  to  support  online  software  development.  These 
terminals  should  be  placed  in  the  programmers'  offices  and  operated  in  local 
mode  over  coaxial  cable  to  an  unclassified  processor.  The  terminals  should 
consist  of  a CRT  with  an  alphanumeric  keyboard  attached.  A few  (one  or  two) 
typewriter  terminals  may  be  desirable  for  hardcopv;  this  is  particularly  useful 
in  an  interactive  debug  mode.  The  CRT  terminals  can  be  shared  between  pairs  of 
programmers . 


Remote  high-speed  printers  are  seldom  desirable  due  to  the  high  noise  level 
of  mechanical  printers. 

Remote  terminals  can  be  shared  between  several  programmers  without  significant 
inefficiencies.  The  actual  ratio  can  only  be  established  through  experience, 
and  is  heavily  dependent  on  the  type  and  amount  of  software  activity  going  on 
at  the  GWC  as  a starting  point.  Considering  that,  on  the  average,  one  of  the 
five  will  not  be  present  to  use  the  terminal  due  to  TDY,  leave,  or  training, 
the  remaining  four  will  each  have  two  hours  per  day  of  terminal  use. 

SUMMARY/ CONCLUSIONS 

The  use  of  remote  terminals  is  recommended  for  programmer  interface  with  the 
GWC  data  system.  Remote  run  card  entry  readers  are  not  considered  to  be 
advantageous  devices  for  programmer  use. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 
A528-1 , 2 
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TRADEOFF  TITLE 


A52-3  What  is  the  tradeoff  between  storage  support  and  capability  for  the 
forecaster  consoles? 

REQUIREMENTS/BACKGROUND 

It  has  already  been  established  that  the  desirable  features  on  the  forecaster 
consoles  will  include  the  accessing,  displaying,  and  modifying  of  large 
portions  of  the  data  base  (see  A54-1).  This  will  require  additional  disk 
storage  associated  with  the  minicomputers  acting  as  interface  between  the 
central  data  base  and  the  forecaster  console.  The  amount  of  storage  required 
may  be  a limiting  factor  on  the  console  abilities. 


DESIGN  APPROACHES/CHARACTERISTICS 

For  this  study,  it  will  be  assumed  that  the  minicomputer  interface  between  the 
central  data  base  and  forecaster  console  will  be  similar  to  the  Interdata  8/32. 
Disk  storage  available  for  this  computer  consists  of  drives  with  2.5,  10,  and 
40  x 106  byte  capacity.  One  control  unit  is  capable  of  handling  up  to  four  disk 
drives.  The  following  table  lists  prices  of  this  hardware: 


Storage 
Capacity 
(bytes  x 10b) 

Disk 
Dri  ve 
Cost 

Control 

Unit 

Cost 

2.5 

$4,000 

$6,000 

10 

$4,500 

$8,500 

40 

$7,000 

$17,750 

ANALYSIS 

Forecaster  consoles  will  be  expected  to  accept,  reject,  modify,  and/or 
combine  presented  information  with  the  goal  of  formulating  a custom-tai lored 
data  set.  This  will  require  an  ability  to  plot  any  data  base  field  from  any 
geographic  area. 
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If  a minicomputer  interfacing  between  data  base  and  forecaster  console  is 
allocated  a control  unit  with  a 4-40  x 106  byte  disk  drives  (at  an  additional 
cost  of  $45,750)  it  would  have  the  storage  area  equivalent  to  about  1/6  of  the 
meteorological  data  base  or  large  enough  to  hold  the  entire  gridded  global 
data  base  of  smooth  DMSP  data. 

Even  if  the  forecaster  should  require  data  from  more  than  1/6  of  the  data  base, 
(and  such  situations  should  be  rare),  the  data  base  manager  will  be  given  the 
ability  to  filter  data  by  type  and  resolution  before  passing  it  on.  This  will 
tend  to  reduce  the  amount  of  storage  needed  for  the  forecasting  console  to  do 
its  work.  Under  these  considerations  even  the  one  control  unit  with  160  x 106 
bytes  storage  becomes  a very  liberal  upper  bound. 

SUMMARY/CONCLUSIONS 

Required  storage  support  should  not  be  a limiting  factor  on  capabilities  for 
the  forecaster  consoles. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

113  - Special  Activities  - Program  D 

115  - Special  Activities  - Agency  B 

120  - Special  Activities  - ZOOM  Use 

217  - Command  Control  Systems  - Crisis  .lanagement 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Enviornmen*al  Support  - Interactive  Processing  and  Display  System 

511  - Space  Environmental  Support  - 0THB  Radar 


RELATED  SPECIFICATIONS 
A52-8,  All  1-1 
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TRADEOFF  TITLE 


A70-1  How  can  the  shortage  of  qualified  Air  Force  programmers  be  alleviated? 

V 

REQUIREMI- NTS/BACKGROUND 

One  of  the  biggest  problems  at  GWC  is  a shortage  i«  manpower,  primarily 
qualified  Air  Force  programmers.  Personnel  authorizations  are  inadequate  and 
current  manning  is  even  below  those.  Approaches  which  will  allow  GWC  to  meet 
requirements  with  this  shortage  of  human  resources  must  be  investigated. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  major  problem  in  AFGWC  software  development  is  the  general  lack  of  manpower 
to  satisfy  user  dictated  requirements.  Several  factors  contribute  to  this 
problem. 

a.  The  military  rotation  policy  prevents  significant  long  term 
continuity  in  the  software  development. 

b.  The  nature  of  the  task  requires  a specific  mix  of  skills.  Many  of 
the  programming  positions  require  advanced  knowledge  in  meteorology 
and  significant  programming  skills  as  well.  Some  of  the  software 
problems  require  skilled  system  programmers;  however,  most  system 
prqgrammers  at  AFGWC  have  meteorology  backgrounds. 

c.  Low  manning  dictates  less  time  devoted  to  training,  both  training 

for  newly  assigned  personnel  and  advanced  training  for  the  experienced 
programmers . 
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The  following  figures  Indicate  current  under-assignment  of  personnel 
NOTE:  Only  76  percent  of  the  authorized  programming  positions  are 

currently  manned. 

AFGWC  Programmer  Manning1 


Branch 


0 


Auth 

Assigned 

112 

80 

71% 

5 

4 

80% 

11 

10 

91% 

.11 

11 

100% 

28 

22 

79% 

167 

127 

76% 

Total  167  127 

Inadequate  personnel  authorization.  Estimates  by  AFGWC  for  required 
manning  to  accomplish  the  "Deficit  Tasks"  indicate  that  additional 
personnel  are  required  to  fulfill  the  requirements  in  a timely  manner 
to  satisfy  customer's  needs.  The  following  figure  contains  the 
estimated  undermanning  by  Branch.  The  specific  requirements  are 
contained  in  the  AFGWC  Deficit  Tasks  memo. 

1 


Fatima ted  Undermannini 


Branch 

WPA 

WPE 

WPF* 

WPD 


Undermanning 

6 man  years 
5 man  years 
40  man  years 
18  man  years 
69  man  years 


Total  69  man  years 

♦Forecasters,  rather  than  programmers. 

Most  of  these  problems  are  inherent  in  the  system  but  can  be  solved  by 
increasing  productivity. 


*As  of  April  1975. 
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ANALYSIS 


The  current  number  of  GWC  programmers  (engaged  in  direct  programming  efforts) 
is  approximately  127  (see  paragraph  6 above  for  branch  breakout).  These 
programmers  are  engaged  in  three  types  of  activity:  maintenance,  enhancement 

and  development. 

Currently  the  training  program  for  the  programmer  consists  of  a six  week 
training  course  taught  by  UNI  VAC.  Once  the  programmers  have  completed  the 
UNIVAC  course,  they  are  assigned  to  a duty  section.  The  assignment  to  a 
specific  section  is  based  on  their  background,  skills  and  interest.  Subsequent 
training  is  accomplished  while  on-the-job  and  basic  ' -y  consists  of  assignments 
that  increase  in  difficulty  as  the  programmer's  skills  improve  in  response  to 
more  experience. 

The  following  profile  of  the  "average  GWC  programmer"  was  developed  from  the 
response  to  the  SDC  software  development  questionnaire  in  March,  1975.  One 
hundred  and  eleven  (111)  questionnaires  were  completed  by  programmers  that 
were  assigned  to  GWC.  This  profile  is  a general  model  and  is  an  average  of  all 
the  questionnaires.  Some  of  the  numbers  have  been  adjusted  to  compensate  for 
obvious  errors  in  the  responses  or  misinterpretation  of  the  questionnaire. 

It  is  important  for  the  reader  to  note  this  profile  is  an  average  and  is  not 
necessarily  congruent  with  ar.y  specific  programmer  at  AFGWC.  For  further 
information  on  programmer  profiles,  several  sample  section  profiles  at  AFGWC 
are  also  attached,  as  Tables  7.1  - 7.5. 


Table  4.  Average  AF6WC  Programmer  Profile 


Lines  of  Fortran  code  responsibile  for  in 

(maintenance) 

7086 

(enhancement) 

1141 

(development) 

1131 

Lines  of  Assembly  code  responsible  for  in 

(maintenance) 

7050 

(enhancement) 

2593 

(development) 

209 

Percentage  of  Total  Individual's  Effort 

(maintenance) 

29% 

(enhancement) 

23% 

(development) 

48% 

Turnarounds  per  week 

12.1 

Average  number  compilations  and/or 

build  run 

5.95 

assemblies  per 

build/execute  run 

4.54 

Average  number  of  executions  per 

execute  run 

1.74 

build/execute  ran 

1.89 

Average  compilation  size  (Fortran) 

lines  of  code 

943 

Average  Assembly  size 

lines  of  code 

145 

Collections  (link  edits)  per 

build 

3.28 

execute 

3.48 

Execution  parameters  per 

words  of  core 

31 K 

build  or  build/execute 

CPU  time  (seconds) 

152.3 

wall  time  (seconds) 

475 

Average  number  of  tapes  utilized  per  run 

programs 

1.3 

data 

. 5 

Average  tracks  of  mass  storage  per  run 

433 

Average  cards  utilized  per  run 

108 

Average  of  print  per  run 

115 

Table  5.  Average  WPP  Programmer  Profile 


Lines  of  Fortran  code  responsible  for  in 

(maintenance) 

5409 

(enhancement) 

1955 

(development) 

781 

Lines  of  Assembly  code  responsible  for  in 

(maintenance) 

436 

(enhancement) 

473 

(development) 

182 

Percentage  of  total  Branch's  effort 

(maintenance) 

35 

(enhancement) 

20 

(development) 

45 

Turnaround  per  week 

18 

Average  compilations  and/or  assemblies  per 

build  run 

6.4 

build  execute  run 

2 

Average  number  of  executions  per 

execute  run 

5 

a 

build/execute  run 

2.5 

Average  compilation  size  (Fortran) 

lines  of  code 

1982 

Average  assembly  size 

lines  of  code 

231 

Collection  (link  edits)  per 

build 

2.4 

execute 

2.8 

Execution  parameters  per 

words  of  core. 

38K 

build  or  build/execute 

CPU  time  (seconds) 

72 

wall  time  (seconds) 

308 

Average  number  of  tapes  utilized  per  run 

programs 

2 

data 

.7 

Average  tracks  of  mass  storage  per  run 

213 

Average  cards  utilized  per  run 

151 

Average  pages  of  print  per  run 

151 

227 


' .......  i,  ..  . . ,.r  • - . : 


Table  6.  Average  WPA  Programmer  Profile 


Lines  of  Fortran  code  responsible  for  in 

(maintenance) 

619 

(enhancement) 

644 

\ 

(development) 

3600 

Lines  of  Assembly  code  responsible  for  in 

(maintenance) 

— 

(enhancement) 

60 

(development) 

— 

Percentage  of  Total  Individual's  effort 

(maintenance) 

3 

(enhancement) 

11 

(development) 

86 

Turnarounds  per  week 

9.7 

Average  number  compilations  and/or 

build  run 

6.75 

assemblies  per 

build/execute  run 

8.25 

Average  number  of  executions  per 

execute  run 

4 

build/execute  run 

4.6 

Average  compilation  size  (Fortran) 

lines  of  code 

1063 

Average  assembly  size 

lines  of  code 

36 

Collections  (link  edits)  per 

build 

10 

execute 

3.75 

Execution  parameters  per 

words  of  core 

68. IK 

build  or  build/execute 

CPU  time  (seconds) 

409 

wall  time  (seconds) 

781 

Average  number  of  tapes  utilized  per  run 

programs 

1.6 

data 

1 

Average  tracks  of  mass  storage  per  run 

125 

Average  cards  utilized  per  run 

156 

Average  pages  of  print  per  run 

115 
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1950 

25 


3.8 

3.8 

81 K 
421 
3188 

5.5 

1 


Table  7.  Average  WPD/RTOS  Programmer  Profile 


Lines  of  Fortran  code  responsible  for  in 

(maintenance) 

(enhancement) 

(development) 

Lines  of  Assembly  code  responsible  for  in 

(maintenance) 

(enhancement) 

(development) 

Percentage  of  Total  Individual's  effort 

(maintenance) 

(enhancement) 

(development) 

Turnarounds  per  week 

Average  number  compilations  and/or 
assemblies  per 

build  run 

buil d/execute  run 

Average  number  of  executions  per 

execute  run 
build/execute  run 

Average  compilation  size  (Fortran) 

lines  of  code 

Average  assembly  size 

lines  of  code 

Collections  (link  edits)  per 

build 

execute 

Execution  parameters  per 
build  or  build/execute 

words  of  core 
CPU  time  (seconds) 
wall  time  (seconds) 

Average  number  of  tapes  utilized  per  run 

programs 

data 

Average  tracks  of  mass  storage  per  run 
Average  cards  utilized  per  run 
Average  of  print  per  run 


Table  8. 


Average  WPJ  Programmer  Profile 


Lines  of  Fortran 

(maintenance) 

7600 

(enhancement) 

172 

(development) 

890 

Lines  of  Assembly 

(maintenance) 

60 

(enhancement) 

-- 

(development) 

__ 

Percentage  of  Total  Individual's  effort 

(maintenance) 

8 

(enhancement) 

13 

(development) 

79 

Turnarounds  per  week 

24.75 

Compilations  and/or  Assemblies  per 

build  run 

4.0 

build/execute  run 

6.5 

Number  of  Executions  per 

execute  run 

1 

build/execute  run 

1.25 

Compilation  size  (Fortran) 

lines  of  code 

240 

Assembly  size 

lines  of  code 

— 

Collections 

per  build 

1 

per  execute 

1 

Execution  parameters  per 

build  or  build/ 
execute 

words  of  core 

54K 

CPU  seconds 

275 

wall  time  seconds 

640 

Tapes  utilized  per 

execution 

1 

programs 

1 

data 

2 

Tracks  of  mass  storage 

120 

Cards  utilized  per 

execution 

44 

Pages  of  print  per 

execution 

155 

mm 


SUMMARY/CONCLUSION 

The  only  obvious  solution  to  handle  GWC's  personnel  problems  are  more 
personnel.  Since  this  does  not  seem  to  be  an  approach  with  which  the  Air  Force 
will  comply  we  must  work  toward  increasing  the  workload  and  output  of 
individual  programmers.  The  means  which  make  this  route  possible  include 
more  software  and  hardware  programing  bocls,  more  uniform  programing  and 
documentation  techniques,  and  a more  sophisticated  programmer  training 
program  (see  Trade  Study  A85-2). 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 

A528-1  through  12,  A72-7,  A921-1 
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TRADEOFF  TITLE 


A70-2  Should  programming  be  Air  Force  or  contractor? 

DESIGN  APPROACHES/CHARACTERISTICS 

Pertinent  conclusions  made  in  Appendix  VI  to  Volume  3 of  the  SADPR-85  study 
are  as  follows: 

ADL  (Arthur  D.  Little,  Inc.)  cites  the  following  sources  from  which  the  Air 
Force  might  acquire  software  during  the  SADPR-85  period  of  interest. 

t Commercial  sources  (including  hardware  vendors)  might  be  used  for 
acquisition  of  standard,  off-the-shelf,  software  packages  from  which 
systems  could  be  assembled  in  "building  block"  fashion. 

• Contract  programming  firms  might  be  hired  to  write  application  and 
system  software  to  Air  Force  specifications. 

• Air  Force  programming  organizations  might  provide  software  design 
and  implementation  services. 

Ultimately,  it  is  expected  that  software  elements  will  be  acquired  from  all  of 
the  above  sources,  although  ADL  predicts  that  the  most  cost  effective  approach 
would  include  use  of  pre-packaged  software  to  the  maximum  extent  possible 
(consistent  with  the  Air  Force's  unique  requirements). 

ANALYSIS 

Analysis  conducted  under  SADPR-85  include  the  following: 

When  contracting  houses  are  selected  as  software  sources,  the  Air  Force  would 
have  to  expect  to  pay  $20-$30  per  programmer  hour.  Offsetting  the  high  costs 
associated  with  these  sources  is  their  high  man-hour  productivity,  which  ADL 
estimates  to  be  50  percent  to  100  percent  higher  than  in-house  Air  Force 
sources . 
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There  are  certain  classes  of  software  which  should  be  developed  exclusively  by 
Air  Force  personnel.  These  include  new  versions  of  applications  programs  with 
which  Air  Force  programmers  are  already  intimately  familiar,  and  those  systems 
programs  whose  logical  procedures  and  structures  directly  reflect  specific 
Air  Force  policies  and  methods  of  operation  (message  switching  software,  for 
example).  The  level  of  effort,  and  therefore  the  costs  associated  with 
in-house  software  development,  will  become  clearer  when  a)  the  software 
entities  to  be  developed  in-house  have  been  identified,  b)  productivity  of 
Air  Force  programmers  has  been  analyzed  more  completely,  and  c)  the  effect 
of  new  software  engineering  techniques  has  been  estimated. 
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REQUIREMENTS/BACKGRQUND 

GWC  will  have  an  ever-increasing  need  to  develop  new  software  to  meet  user 
requirements.  GWC,  however,  will  also  be  faced  with  a shortage  of  qualified 
programmers.  This,  in  fact,  may  be  typical  of  a problem  that  will  be  prevalent 
in  much  of  the  Air  Force.  Attention  was  directed  to  this  situation  in  a study 
recently  sponsored  by  the  Air  Force  Electronic  Systems  Division  entitled 
"Support  of  Air  Force  Automatic  Data  Processing  Requirements  Through  the 
1980's  (SADPR  85)."  This  report  identifies  the  total  automatic  data  processing 
(ADP)  requirements  of  base  level  organizations  (i.e.,  USAF  operational  support 
organizations  below  the  major  command  headquarters  level)  through  the  1980's, 
provides  feasible  automatic  data  processing  system  (ADPS)  concepts  and 
alternative  system  configurations  for  satisfying  those  requirements,  and 
suggests  an  implementation  plan  for  the  options  chosen. 

Since  the  SADPR-85  Data  Project  Directive  called  for  planning  a system  for 
implementation  in  the  late  1970s  and  early  1980s,  an  understanding  was  needed 
of  the  data  processing  and  communications  capabilities  and  costs  likely  to  be 
available  at  that  time.  Previous  technology  forecasts  generally  dealt  with 
components  and  the  state-of-the-art  in  research  and  development.  SADPR-85, 
however,  must  be  able  to  be  implemented.  Therefore,  the  technology  of 
interest  must  have  been  proved  by  application  and  must  be  described  in  terms 
of  system  components  which  will  be  available  on  competitive  bids  from  ADPE 
vendors. 
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The  Study  Team  understands  that  a controlled  data  base  for  use  with  the  Data 
Automation  Planning  and  Resource  Management  Information  System  is  under 
development,  and  that  within  the  next  year  it  should  yield  valid  assessments 
of  current  manpower  needed  to  perform  system  analysis,  programming,  test,  and 
maintenance  tasks.  The  resultant  manhour  figures,  gathered  at  the  Air  Force 
Data  Systems  Design  Center,  will  then  be  used  to  estimate  the  manpower  needed 
for  future  software  development  efforts. 

SUMMARY/CONCLUSIONS 

It  appears  that  a judicious  mix  of  commercial  sources,  contract  programming 
firms,  and  Air  Force  programming  organizations  would  provide  the  most 
cost-effective  approach  to  procuring  required  software.  While  maximum  use  of 
"pre-packaged"  software  is  encouraged,  GWC  will  be  required  to  implement  a 
large  percentage  of  new  and  unique  software  for  a wide  variety  of  applications 
and  system  support  requirements.  The  optimum  mix  of  Air  Force-contractor 

i 

programming  for  applications  software  should  await  the  results  of  Air  Force 
studies  that  will  determine: 

a.  exact  identification  of  the  software  entities  to  be  developed, 

b.  productivity  of  Air  Force  programmers  has  been  analyzed, 

c.  effects  of  new  software  engineering  techniques  have  been  estimated. 

A summary  of  some  of  the  prime  candidates  for  vendor  or  outside  contractor 
supply  in  the  support  area  are  indicated  in  Table  7.6. 

pELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

100  - General  - All 

2 OS  - Command  Control  System  - TAC 

216  - Command  Control  System  - AWACS 

218  - Command  Control  Systems  - Computer  Flight  Plans 

300  - Emergency  War  Order  Support  - All 
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400  - Environmental  Support  - All 
500  - Space  Environment  Support  - All 
602, - General  - Manpower  Productivity 
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RELATED  SPECIFICATIONS 
A331-1  through  18,  A72-7 


TRADEOFF  TITLE 


A71-1  What  is  the  personnel  requirement  based  on  the  automatic  work  center 
design? 

REQUIREMENTS/BACKGROUND 

A distinct  need  exists  to  automate  the  operations  of  GWC  as  much  as  is 
feasible.  This  is  especially  important  in  the  light  of  the  possibility  of 
reduced  manning  levels  and  the  need  to  accommodate  ever-increasing  user 
requirements.  To  fill  this  need,  the  concept  of  Automated  Work  Centers  (AWCs) 
to  support  operator  actions  has  been  developed.  These  centers  will  be 
specialized,  but  the  equipment  for  each  AWC  will  be  assembled  from  a battery 
of  standard  devices  (e.g.,  CRTs  and  plotters)  that  will  be  a part  of  the 
selected  GWC  architecture.  Categories  of  these  AWCs  are: 

a.  Forecasting  centers, 

b.  System  control  centers,  and 

c.  System  support  centers. 

DESIGN  APPROACHES/CHARACTERISTICS 


AWC  design  considerations  and  guidelines  include  the  following: 

a.  Minimizing  the  total  number  of  operations, 

b.  Relative  costs  of  automation  vs  manual  techniques, 

c.  Segregation  of  work  areas  into  normal  and  special  access  areas, 

d.  Implementation  of  the  system  network  control  concept, 

e.  Tradeoffs  between  centralized  and  dedicated  support  centers, 

f.  Desirability  of  interactive  software  development  and  remote  job 
entry, 

g.  Ease  of  phaseover,  and 

h.  Tradeoffs  between  central  computers  and  minicomputers  for  interrupt 
handl ing. 
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Analyses  have  considered  these  guidelines  in  conjunction  with  the  basic 
assembly  of  AWC  hardware  components  specified  for  these  architectures  to 
develop  required  numbers  of  personnel  to  man  these  positions. 

ANALYSIS 

The  number  of  personnel  allocated  to  each  of  the  console  positions  is  based 
on  the  following  rationales: 

a.  Forecasting  Centers 

As  Indicated  in  Table  7.7,  numerous  classified  and  unclassified 
Forecaster  Consoles  will  be  manned  by  WPF,  WPE,  and  WPJ  personnel. 
The  WPF  and  WPJ  functions  are  assumed  to  be  sufficiently  complex 
to  warrant  two  operators  per  shift.  In  WPF,  teams  would  consist 
of  one  assisting  observer  and  one  forecaster  per  center,  while  WPJ 
would  man  their  centers  with  two  man  "technician-meteorologist" 
teams  to  fulfill  their  functions.  WPE  centers  would  occasionally 
require  2-man  teams  to  perform  operations  but  the  average  should 
not  exceed  one  man. 

Automation  should  cause  a reduction  in  the  WPF  observer  staff.  It 
is  assumed  that  six  observer  positions  (slots)  can  be  eliminated 
through  automation  by  1982. 

b.  System  Control 

Table  7.1  indicates  that  network  control,  computer  operations, 
and  communications  consoles  will  each  be  manned  by  2 WPD  men.  In 
each  of  these  2-man  teams,  activities  will  be  shared  between 
skilled  technicians  of  approximately  equal  capabilities  with  one 
acting  as  the  senior  man  in  charge.  (These  functions  are  judged 
to  be  sufficiently  complex  to  warrant  two  men  per  console  to 
adequately  monitor  and  control  required  operations).  Security 
monitoring,  however,  can  be  accomplished  with  one  man  per  console, 
while  the  maintenance  consoles  will  on  the  average  be  manned  less 
than  50%  of  the  time.  In  addition,  a console  for  remote 
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Table  10.  Console  Personnel  Allocation 


Work  Center 

No.  of 

Personnel 

Slots 

Total 

Primarv 

Category  Function 

Consoles 

Per  Console 

Per  Shift  Slots  GWC  Org 

Forecasting 

TAF-MET 

17 

2 

34 

170 

GF 

. (UNCLASSIFIED) 

SESS 

(UNCLASSIFIED) 

2 

1 

2 

10 

SF 

SESS 

(CLASSIFIED) 

1 

1 

1 

5 

SF 

SX 

(CLASSIFIED) 

4 

2 

8 

40 

SX 

System  Control 

NETWORK 

CONTROL 

1 

2 

2 

10 

AD 

COMPUTER 

OPS 

2 

2 

4 

20 

AD 

COMM 

2 

2 

4 

20 

AD 

MAI  NT 

5 

*** 

2 

10 

AD 

SECURITY 

MONITOR 

2 

1* 

2 

10 

AD,  SX 

REMOTE 
JOB  ENTRY 

1 

_* 

_* 

_* 

_* 

System  Support 

SPECIAL 

OPS 

1 

1 

2 

2 

10 

AD 

QUALITY 

ASSURANCE 

1 

1 

1 

5 

AD 

PRINTER 

CONTROL 

1 

0.5 

0.5 

2.5 

AD 

ARCHIVAL 

CONTROL 

1 

0.5 

0.5 

2.5 

AD 

SATELLITE 
DATA  SUPPORT 

2 

2 

4 

20 

AP 

SID 

2 

2 

2 

20 

AP 

SOFTWARE 

DEVELOPMENT 

30 

-r — As  r rn 1 n 

AD,  SA 

nJ  [\L.W  U — — — 

TOTALS 

72 

71** 

355** 

*R0E  console  monitor  by  a security  monitor  console  operator 
Plus  use  by  AD,  SA  personnel  as  required. 

***An  average  loading  of  two  men  for  the  five  maintenance  consoles  is  assume 
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job  entry  monitoring  can  also  be  maintained  by  the  WPD  operator 
in  charge  of  the  normal  access  security  monitoring  console. 

In  addition,  it  is  expected  that  WPD  can  experience  a reduction 
of  two  programmer  slots  for  program  development  due  to  automation. 

This  is  based  on  the  assumption  that  of  the  70$  of  the  100  program- 
mers in  WPD  involved  in  program  maintenance  about  3$  can  be  eliminated 
due  to  automated  techniques. 


c.  System  Support 

Special  operations,  satellite  data  support,  and  satellite  imagery 
dissemination  are  all  sufficiently  complex  functions  to  warrant 
two  highly  qualified  operators;  possibly  one  officer  and  one 
skilled  technician  per  console.  Quality  assurance,  however,  can 
be  accomplished  with  one  WPD  operator,  while  a single  WPD  operator 
should  be  sufficient  to  cover  both  printer  control  and  archival 
control  functions.  There  will  be  numerous  consoles  devoted  to 
software  development  to  be  used  on  an  as-needed  basis  by  WPD  and 
WPA  personnel . 


Automation  should  reduce  the  required  levels  of  WPA  and  WPD 
programmers  involved  in  new  program  development.  In  WPA,  of  the 
70$  of  the  20  programmers  doing  new  program  development  (14 
programmers),  about  20$  (3  men)  could  be  eliminated.  In  WPD 
assuming  30$  of  the  100  programmers  are  involved  in  developing 
new  programs,  and  assuming  20$  of  these  can  be  eliminated  via 
automated  techniques,  a net  WPD  savings  of  6 could  result. 

SUMMARY/CONCLUSIONS 

Table  7.1  summarized  the  numbers  of  personnel  associated  with  the  various 
forecasting  system  control,  and  system  support  consoles,  and  expands  these 
figures  to  total  personnel  slots  by  using  a factor  of  5 to  permit  24  hour 
a day  - seven  day  a week  coverage.  It  is  important  to  note,  however,  that 
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although  many  of  these  positions  are  new  to  GWC  in  concept  (e.g.,  network 
control),  automation  and  its  resulting  efficiencies  will  permit  existing 
personnel  to  perform  these  functions.  In  fact,  some  net  reductions  in 
manning  will  occur.  Table  7.8  summarizes  personnel  allocations  on  an 
organizational  basis,  indicating  the  percentages  of  organization  personnel 
that  will  be  involved  w'th  Automated  Work  Centers.  Overall,  it  can  be  seen 
that  well  over  half  of  the  personnel  in  these  six  line  organizations  will 
be  actively  using  these  Automated  Work  Centers  to  perform  their  duties. 

Table  11.  Impact  of  Automation  On  Selected  GWC  Organizations 

ASSIGNED  INCREASED  1982  SLOTS  NET  SLOTS  % OF  SLOTS 

SLOTS-  77-82  EXPECTED  SAVED  THRU  SLOTS  EMPLOYING  EMPLOYING 
ORG  1975  REQ'TS*  MANNING**  AUTOMATION  1982**  AWCs  1982  AWCs** 


85**** 

45%**** 

40 

67% 

Used  as 

As 

355****  55**** 


* Based  on  new  user  and  model  requirements 

**  Assuming  increases  to  1975  level  only  to  directly  meet  new  requirements. 

***  2 for  program  maintenance, 

6 for  program  development 

****Plus  use  of  software  development  consoles  as  required 


RELATED  REQUIREMENTS 


This  Trade  Study  Is  related  to  the  following  requirements: 

120  - Special  Activities  - ZOOM  Use 

217  - Command  Control  System  - Crisis  Management 

406  - Environmental  Support  - Satellite  Imagery  Dissemination 

408  - Environmental  Support  - Interactive  Processing  and  Display  System 

602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 

A20-1,  2,  A50-4  through  8,  A511-2  through  8,  A512-5  through  8,  A513-9,  A514-1 
through  5,  A516-1,  A52-10  through  18,  A525-4  through  7,  A526-1 , A527-3  throuc' 
9,  A528-11,  12,  A529-3  through  5,  A813-1,  6,  A813-16  through  A813-23,  A71-1 
through  6,  A72-1  through  8,  A73-1 
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TRADEOFF  TITLE 

A81-1  Should  there  be  modifications  to  the  AFGWC  organizational  structure  and 
associated  responsibilities? 

REQUIREMENTS/BACKGROUND 

As  assessment  has  been  made  of  the  AFGWC  organizational  structure  by  evaluating 
the  impact  of  major  new  requirements  on  GWC  operations.  Consideration  has  also 
been  given  to  the  effect  of  the  new  data  system  architecture,  including  the 
implementation  and  Integration  process,  on  staff  and  line  operations  personnel. 

DESIGN  APPROACHES/CHARACTERISTICS 

As  stated  in  the  Task  1 briefing,  SDC  considered  the  basic  AFGWC  organizational 
structure  that  existed  at  that  time  to  be  adequate;  that  is,  the  breakdown  into 
four  staff  organizations  (DA,  DO,  IN,  and  CCQ),  two  field  locations  (OL-A  and 
OL-B),  and  seven  Branch  organizations  (SA,  AP,  SX,  AD,  GF,  SF,  and  LG)  appeared 
to  be  well  suited  to  GWC  missions  and  responsibilities.  For  the  most  part,  SDC 
still  believes  that  the  newly  proposed  overall  GWC  organizational  heirarchy, 
which  includes  ETAC,  Carswell,  the  Second  Weather  Squadron,  and  the  Moffett 
operating  location,  is  well  organized  to  meet  GWC  responsibilities.  (This 
proposed  structure  is  shown  in  Figure  8.3).  However,  within  certain  elements 
of  these  organizations,  some  restructuring  is  possible  to  optimize  GWC  operations 
under  the  new  architecture.  The  three  major  units  that  appear  to  be  affected 
organizationally  are: 

a.  Operations  Staff  (DO)  Primarily  because  of  responsibilities  to  imple- 
ment and  validate  new  hardware  and  software; 

b.  Data  Acquisition  and  Processing  Branch  (WPP)  Primarily  because  of 
requirements  to  process  greater  amounts  of  satellite  data  of  different 
types  and  because  of  requirements  to  distribute  this  data  through  the 
Satellite  Information  Dissemination  System;  and 

c.  Data  Automation  Branch  (WPP)  Mainly  due  to  a reorientation  of  person- 
nel to  man  Automated  Work  Centers  for  machine  operations  (along  with 
maintaining  associated  software),  and  to  develop  software  to  meet 
several  new  model  and  user  requirements. 
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ANALYSIS 

Except  for  DO,  no  consideration  has  been  given  in  this  trade  study  to  restructur- 
ing GWC  liaison  or  staff  organizations.  Most  of  the  functions  of  these  units  are 
employed  to  maintain  administrative  efficiency  within  GWC,  and  are  not  expected 
to  require  changes  as  a result  of  a new  data  system  architecture  or  new  require- 
ments. DO,  however,  will  probably  realize  an  expanded  role  as  new  data  system 
components  are  acquired,  integrated,  and  validated.  Thus,  as  illustrated  in 
Figure  8.4,  it  is  suggested  that  distinct  responsibilities  be  set  up  within  DO 
for  acquisition/integration  and  configuration  control  (configuration  control  is 
often  structured  as  one  subset  of  integration  activities,  but  since  these  kinds 
of  hardware  and  software  maintenance  activities  are  so  critical  to  GWC,  this 
function  should  be  Given  key  prominence  in  the  DO  staff).  The  day-to-day 
functions  of  Production  Division  operations  support,  as  well  as  requirements 
analysis  and  planning  activities,  will  remain  as  primary  responsibilities  of  DO, 
as  shown  in  Figure  8.4.  In  keeping  with  this  new  long-term  enphasis  on  data 
system  integration,  a suggested  new  title  for  this  entity  is  the  "Operations  and 
Integration  Staff". 

It  should  be  noted  that  in  accomplishing  software  configuration  control,  DO 
will  be  involved  with  both  in-house  and  outside  contractor  personnel.  DO  will 
therefore  be  in  the  position  of  enforcing  established  Air  Force  configuration 
management  guidelines  on  contractor  personnel,  as  well  as  controlling  the 
production  and  maintenance  of  In-house  software.  All  products  should  be  docu- 
mented, produced,  and  maintained  according  to  a consistent  set  of  standards. 

The  enforcement  of  these  rules  should  be  the  responsibility  of  DC  To  enable 
this  configuration  control  and  contractor  management,  DO  may  require  a staff 
that  is  more  oriented  towards  the  computer  sciences  and  systems  engineering. 

This  increased  emphasis  on  computer  systems  analysis  backgrounds  will  not  only 
ensure  the  success  of  computer  systems  implementation,  but  will  also  further 
guarantee  the  success  of  other  related  long-term  planning  efforts. 
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Most  of  the  Branch  organizations  in  the  Production  Division  need  not  necessarily 
undergo  realignment  because  of  the  new  requirements  or  because  of  a new 
architecture.  While  some  requirements  and  proposed  hardware  and  software 
components  may  profoundly  affect  the  ways  in  which  activities  are  accomplished, 
these  tasks  can,  for  the  most  part,  still  be  done  under  current  personnel 
hierarchies.  The  Studies  and  Analysis  Branch,  for  example,  will  be  involved 
in  the  development  of  numerous  new  models  over  the  next  several  years,  but  as 
is  the  case  now,  there  will  be  much  overlap  between  computer  scientists, 
mathematicians,  and  meteorologists  in  this  area,  many  of  whom  will  simultaneously 
be  involved  with  more  than  one  computer  program.  A rigid  structuring,  therefore, 
of  this  branch  does  not  appear  to  be  justified. 

The  same  is  true  of  the  Special  Projects,  Space  Environmental  Support,  and 
Intelligence  Branches:  activities  within  these  organizations,  even  considering 

the  impact  of  the  new  architectures,  should  still  be  feasible  within  current 
organizational  frameworks.  Similarly,  while  forecaster  consoles,  new  models, 
and  new  user  requirements  may  greatly  change  the  methods  by  which  observers 
and  forecasters  execute  their  duties,  these  methods  should  be  accommodated  by 
the  present  structure.  That  is,  teams  of  observers  and  forecasters,  generally 
allocated  to  geographical  areas,  should  still  be  a reasonable  way  to  operate. 

The  Data  Acquisition  and  Processing  Branch,  however,  can  benefit  from  some  re- 
orientation at  the  lower  levels  to  reflect  the  impact  of  satellite  data  input 
and  output  requirements.  As  shown  in  Figure  8.5,  Operations  and  Program  Develop- 
ment sections  are  reasonable  divisions  of  responsibility  within  the  Branch,  but 
within  each  section,  processing  of  new  data  sources  and  the  semi -automated 
dissemination  of  this  processed  data  should  receive  special  attention.  A 
suggested  more  descriptive  title  for  this  Branch  is  "Satellite  Data  Processing 
Branch". 
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Figure  8.6  illustrates  several  suggested  changes  to  the  Data  Automation  Branch 
structure: 

a.  Machine  Operations  Section.  This  new  structure  reflects  the  advent  of 
numerous  Automated  Work  Centers  that  will  be  used  by  machine  operations 
personnel . 

b*  Computer  Flight  Plans  Section.  No  changes  anticipated  - this  function 
will  take  on  more  importance  with  the  influx  of  new  CFP  requirements 
in  the  1977-82  time  frame. 

c.  Mission  Applications  Section.  This  section  has  been  structured  to 
emphasize  some  of  the  major  new  software  development  and  maintenance 
efforts  that  will  be  required. 

d.  Environmental  Data  Systems  Section.  No  basic  changes,  although  this 
section's  substructure  has  been  set  up  in  part  to  emphasize  the  large 
development  efforts  that  are  expected  in  data  base  software  and  in 
executive  program  conversion. 

e.  Data  Handling  Section.  This  entity  was  retitled  from  its  former  name 
of  "Data  Processing  Section"  to  more  accurately  describe  its  present 
and  proposed  functions.  Its  structure  is  intended  to  allocate  personnel 
to  the  coding,  conversion,  and  maintenance  of  front-end  decoders  and 

to  the  development  of  software  for  new  communications  processing 
functions . 

f • Operations  Support  Section.  This  is  a new  unit  within  this  Branch, 
and  is  oriented  toward  any  development  and/or  maintenance  that  will 
be  required  of  GWC  to  accommodate  the  functions  of  the  system  control 
and  system  support  Automated  Work  Centers.  In  the  more  distant 
future,  this  group  could  develop  software  for  other  specialized 
operations,  such  as  unique  support  for  the  Interactive  Processing 
and  Display  System,  that  might  supplement  contractor  efforts. 
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Two  technically-oriented  organizations  that  are  new  to  the  AF6WC  structure  are 
the  Aerospace  Sciences  Staff,  which  will  report  directly  to  the  commander  but 
will  work  in  close  conjunction  with  the  Studies  and  Analysis  Branch,  and  the 
Current  Operations  Branch,  w/itch  will  closely  monitor  the  production  efficiency 
of  the  Division  (especially  the  operations  of  the  Global  Environmental  Applica- 
tions Branch)  by  working  with  all  line  organizations.  Both  of  these  units  will 
further  serve  to  guarantee  the  success  of  the  AFGWC  mission  through  efficient 
advanced  analyses  and  more  thorough  quality  control. 


SUMMARY/CONCLUSIONS 

Most  1977-82  requirements  can  be  accommodated  with  modest  changes  to  the  GWC 
organizational  structure  as  currently  proposed.  Greater  emphasis  should  be 
placed  on  acquisition  and  integration  activities  in  the  operations  staff  (now 
recommended  to  be  reporting  to  the  commander  of  all  AFGWC  operations),  on  the 
input  and  output  of  satellite  data  in  the  current  Data  Acquisition  and  Processing 
Branch,  and  on  new  responsibilities  in  .he  Data  Automation  Branch.  While  the 
nature  of  activities  within  other  Branches  may  be  greatly  affected  by  the  new 
architecture,  these  new  tasks  can  be  accomplished  within  current  organizational 
frameworks. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 


RELATED  SPECIFICATIONS 
A811-1  through  12 
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TRADEOFF  TITLE 

A81-2  What  is  the  level  to  which  operations  management  is  considered  in 
developing  the  network  controller  concept? 

REQUIREMENTS/BACKGROUND 

The  concept  of  network  control  is  a change  from  current  operations.  Specifically 
it  takes  scheduling  activity  away  from  the  man  as  a real-time  function  and 
automates  it.  He  must  therefore  preplan.  The  changes  in  operation  management 
are  critical  to  the  operations  of  GWC. 

DESIGN  APPROACHES/CHARACTERISTICS 

Several  things  were  considered  in  conceiving  the  Network  Control  System: 
a)  minimum  deviation  from  current  organizational  entities  and  individual 
responsibilities  were  assured;  b)  the  present  task  scheduling  technique  was 
totally  automated  providing  more  efficiency  wherever  possible;  c)  a simple 
control  data  base  was  established  so  that  the  Network  Controller  could  know 
precisely  what  priority  decisions  would  be  made  and  would  only  have  to  inter- 
vene in  the  automated  process  when  the  previous  plan  was  no  longer  valid; 
d)  the  inability  of  the  operating  components  to  individually  or  totally  meet 
tasking  demands  is  immediately  brought  to  the  attention  of  the  Network 
Controller. 

The  Network  Controller  is  the  person  responsible  for  the  data  system.  In  the 
operational  organization,  he  is  in  charge  of  individuals  manning  the  operational 
console  position,  the  security  monitor  position,  the  comm  control  position  (not 
the  entire  comm  function),  and  the  maintenance  function.  The  role  is  more 
centralized  to  the  degree  that  one  person  is  responsible  for  activities  in 
both  computational  perimeters  (normal  and  special  access). 

One  of  the  most  significant  changes  in  new  data  system  concepts  over  old  ones 
is  the  ability  to  reconfigure  and  to  automatically  provide  the  capability  to 
upgrade  and  downgrade  computers  prior  to  accomplishing  a task  of  another 
security  classification.  Any  time  there  is  a configuring  of  physical  entities 
into  logical  entities,  this  produces  an  additional  burden  on  the  network 
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controller  in  his  requirement  for  visibility  of  the  system.  This  is  the  area 
where  human  factors  of  the  network  control  console  will  be  key  in  the  design. 

ANALYSIS 

A network  control  scenario  might  help  clarify  the  network  control  function  and 
its  management  aspects.  We  must  assume  that  the  system  exists  at  some  arbitrary 
state  in  terms  of  resource  assignments  to  each  other  and  to  security  level. 
There  is  a central  queu*  which  is  the  master  task  scheduler  under  tt.e  control 
of  the  network  control  computer  and  available  for  reference  by  the  Network 
Controller.  When  a task  is  to  be  run,  the  desire  to  run  it  is  entered  into 
this  queue. 

Each  task  has  stored  in  the  data  bases  certain  characteristics  parameters  (or 
they  are  assumed).  These  include  security  level,  activation  time  (if  not 
current),  distribution  of  run  time,  ability  to  be  interrupted,  time  period 
within  which  the  task  must  be  run,  any  special  links  to  other  tasks,  and 
security  level  of  the  task. 


A dynamic  priority  queue  is  utilized.  This  means  that  when  items  are  entered 
into  the  queue  they  are  done  so  according  to  a priority  level.  If  desired,  the 
priority  label  can  change  as  a function  of  time  (i.e.,  age).  As  a job  gets 
closer  to  its  due  time,  then  its  priority  will  increase.  Due  time  itself  is 
a parameter  which  may  be  entered  in  a variety  of  ways,  either  linked  with 
another  task,  or  entered  as  an  absolute. 

Whenever  a job  is  to  be  run,  a resource  is  sought.  The  Network  Control  Monitor 
scans  activities  within  each  system  component.  Based  on  nominal  times,  it 
knows  when  the  component  will  become  available.  It  also  knows  what  the  present 
classification  level  is  and  whether  a change  is  needed  to  run  the  task  in  the 
queue.  There  is  also  an  indication  of  other  factors  which  might  make  bene- 
ficial uses  automatically  of  what's  left. 
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The  role  of  the  human  interface  (i.e..  Network  Controller)  during  this  time 
is  a monitoring  or  override  function.  He  has  the  capability  to  determine 
resource  assignments,  task  assignments  and  the  status  of  each  task  as  compared 
to  the  nominal  or  average  characteristics  of  that  task.  His  manual  control 
function  is  simply  one  of  being  able  to  modify  any  of  the  scheduling  control 
parameters.  He  may  change  the  priority  or  characteristics  associated  with  any 
of  the  jobs,  thereby  causing  it  to  be  processed  differently.  He  can  limit  the 
configuration  options  associated  with  the  hardware  components  by  modification  of 
the  configuration  option  list.  He  can  reserve  components  by  removing  them  from 
action  or  he  can  isolate  a component  set  for  a checkout  or  maintenance  function. 
He  is  indeed  in  complete  control  of  data  system  activities. 

The  ability  to  constrain  the  number,  of  options  available  for  system  configura- 
tion is  important.  One  can  specify  a configuration  exactly  like  the  one  that 
exists  at  6WC  today,  i.e.,  where  processors  are  always  configured  to  a certain 
security  level.  Or  the  system  can  be  configured  to  its  maximum  efficiency 
(greatest  changeability).  If  desired,  the  amount  of  switching  of  components 
or  security  downgrades  can  be  minimized  through  constraining  the  reconfiguration 
opti ons . 

SUMMARY/CONCLUSIONS 

Operations  management  is  changed  to  the  extent  of: 

a.  consolidating  the  operational  control  function, 

b.  putting  preplanning  parameterization  in  place  of  real-time 
planning, 

c.  providing  direct  one  person  control  when  unforseen  anomalies 
arise. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

600  - General  - All 

RELATED  SPECIFICATIONS 


A813-1 
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TRADEOFF  TITLE 


A81-3  How  far  should  we  go  in  multi tasking-especially  a single  CPU? 
REQUIREMENTS/BACKGROUND 

The  process  of  assigning  more  than  one  function  at  a time  to  a CPU  is  known  as 
multitasking.  This  study  involves  a tradeoff  between  accomplishing  one  func- 
tion as  quick  as  possible  or  running  as  many  functions  as  possible  within  a 
longer  period  of  time. 

DESIGN  APPROACHES/CHARACTERISTICS 
There  are  two  basic  approaches: 

a.  Allow  only  one  task  at  a time  to  be  associated  with  a given  CPU, 
and 

b.  Allow  a sufficient  number  of  tasks  to  be  worked  on  simultaneously 
so  that  a maximum  efficiency  rate  can  be  achieved  with  the  CPU 
while  all  time  lines  are  met. 

ANALYSIS 

Examination  of  the  "average*  GWC  function  has  shown  that  as  many  as  2.19  may 
operate  simultaneously  and  still  complete  within  their  expected  wall  times. 

It  would  therefore  be  a waste  of  CPU  resource  to  have  as  little  as  1 "average" 
function  active  in  a system  at  a time. 

The  GWC  network  is  not  made  up  of  "average"  functions  however,  so  the  2.19 
figure  cannot  be  applied  without  further  study.  This  is  where  the  simulation 
models  come  into  play  as  a tool  which  may  help  to  predict  how  much  multitasking 
is  reasonable. 

SUMMARY/CONCLUSIONS 

Multitasking  should  be  strived  for  to  the  maximum  extent  that  the  individual 
functions  and  their  time  lines  allow. 
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RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements: 
No  requirements. 

RELATED  SPECIFICATIONS 


A311-8  through  9,  A264-3,  4 


TRADEOFF  TITLE 

A81-4  To  what  extent  should  functions  be  centralized  as  they  are  in  the 
current  operating  system? 

REQUIREMENTS/BACKGROUND 

Centralization  of  functions  is  desirable  because  of  the  natural  ability  to 
schedule  synchronous  activities  or  at  least  those  on  the  same  time  base.  It 
is  further  desirable  due  to  the  centralization  of  software  and  obviating 
reading  continuous  processing  software  in  and  out  of  core.  Centralization 
avoids  the  switching  of  resources  such  as  external  communications  lines  of 
consoles.  Finally,  components  can  be  specially  constructed  to  best  adapt  to 
the  functions. 

The  disadvantage  of  centralizing  functions  is  the  requirement  for  a total 
backup,  the  inability  to  smooth  out  peaks  and  valleys  in  loading  between 
various  functions  and  the  impact  of  growth  and  change  on  the  system  configura- 
tion (requiring  a complete  redesign). 

DESIGN  APPROACHES/CHARACTERISTICS^ 

(See  REQUIREMENTS/BACKGROUND) 

ANALYSIS 

Avoidance  of  maximum  security  within  a processor  or  data  base  subsystem  requires 
centralization  for  each  security  classification  level.  We  recommend  however 
that  the  software  be  written/changed  to  force  a maximum  amount  of  computation 
to  be  accomplished  at  the  unclassified  level  where  the  computation  is  indeed 
unclassified  and  other  overriding  considerations  are  not  present.  Beyond  that, 
the  degree  of  required  centralization  becomes  a function  of  the  ability  to 
allocate  resources  within  a prespecified  data  base  environment  and  the  avoidance 
of  additional  cost  due  to  added  complexity  ir.  trying  to  generalize  the 
application  of  resources.  In  general,  we  want  to  provide  a batch  processing 
system  and  have  proposed  a prioritized  dynamic  network  queue  along  with  roll- 
in/roll-out  and  job  reallocation  capabilities  to  accomplish  our  objective. 
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SUMMARY/CONCLUSIONS 


The  only  two  areas  which  are  exceptions  (to  the  extent  that  someone  needs  to 
feel  the  responsibility)  are  network  control  and  master  data  base  management. 
Network  control  has  to  be  the  central  scheduler  of  jobs  and  therefore  must  be 
one  resource  which  is  identifiable.  Other  resources,  however,  have  to  sense 
whether  or  not  he  is  doing  this  job  properly  and  therefore  taking  over  the  job 
when  required.  The  data  base  manager,  we  feel,  has  to  respond  quickly  and  we 
are  not  certain  that  going  through  the  network  scheduling  loop  would  accomplish 
this  job  in  a rapid  enough  manner  and  therefore  have  dedicated  it  to  a single 
computer.  Except  for  the  jobs  which  have  been  centralized  to  different 
computers  (e.g.,  array  processors  or  comm  processors)  we  feel  the  rest  of  the 
system  should  run  on  batch  basis  under  the  constraints  of  security. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

602  - General  - Manpower  Productivity 


RELATED  SPECIFICATIONS 
A132-1 , A813-2 
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TRADEOFF  TITLE 


A81-5  Should  automatic  scheduling  be  used  or  should  the  manual  mode  be 
continued? 


REQUIREMENTS/BACKGROUND 

On  the  surface,  because  of  components  required  for  reliability,  there  does  not 
appear  to  be  a great  need  for  detailed  scheduling.  Not  immediately  apparent 
is  that  the  ability  to  schedule  determines  the  redundancy  required  to  meet 
requirement  reliability. 


DESIGN  APPROACHES/CHARACTERISTICS 


We  can  either  continue  with  manual  scheduling  or  develop  a Network  Control 
concept  which  automates  this  function. 


ANALYSIS 


The  ability  to  schedule  to  minimize  waste  is  equivalent  to  keeping  redundant 
resource  to  support  peak  load  operations.  The  better  the  scheduler,  the 
cheaper  the  system.  Within  current  operations,  there  is  approximately  43% 
wait  time  associated  with  computer  runs.  This  can  be  reduced  to  say  10%; 
then  about  1/3  of  the  total  resource  will  not  be  required.  A good  scheduling 
program  can  be  developed  for  2 - 3 million  dollars  and  resource  that  it  may 
save  amounts  to  10  or  20  million  dollars.  The  ability  to  schedule  also 
reduces  the  need  to  centralize  common  functions.  The  noncentralization  of 
functions  results  in  more  efficient  system  usage.  The  end  result  is  again  a 
savings  in  resource. 


Another  consideration  is  the  switching  of  components  to  recover  from  malfunc- 
tions and/or  distributed  peak  load  conditions.  In  the  environment  of  two- 
minute  requirements,  we  do  not  feel  the  manual  counterpart  to  the  switching 
function  would  assure  meeting  the  requirements.  As  a consequence,  the  automatic 
switching  portion  of  the  network  scheduling  function  is  mandatory. 
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SUMMARY/CONCLUSIONS 

Under  the  previous  system,  the  cost  of  a central  network  scheduler  was  not 
justified  nor  was  the  ability  to  solve  the  security  problems  associated  with 
it.  Under  the  conditions  of  design  against  a strict  reliability  requirement, 
the  network  scheduler  is  well  justified. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

602  - General  - All 

RELATED  SPECIFICATIONS 
A813-1 


262 


TRADEOFF  TITLE 


A81-6  What  is  the  tradeoff  between  one  and  two  network  control  systems? 
REQUIREMENTS/BACKGROUND 

Precedence  which  dictates  complete  separation  of  normal  and  special  access 
functions  is  riot  corisistent  with  current  design. 

DESIGN  APPROACHES/CHARACTERISTICS 

A single  network  control  function  requires  significant  communications  between 
the  normal  and  special  access  areas.  Two  functions,  however,  obviate  the 
ability  to  keep  computation  at  the  lowest  level. 

ANALYSIS 

The  decision  to  operate  and  compute  at  the  security  level  of  computation  and 
data  necessitates  moving  many  special  access  time  critical  functions  outside  of 
the  special  access  perimeter  into  the  other  computation  components.  The 
results  are  then  sent  back  over  the  one-way  communication  channel  to  the  special 
access  computers  where  the  results  are  used  for  computation.  We  feel  that  this 
interaction  requires  precise  scheduling  of  resources  and  single  point  know- 
ledge of  what  is  to  be  accomplished.  Since  the  network  control  interface  is 
a control-only  data  line,  it  was  felt  that  this  function  could  take  place 
within  the  special  access  perimeter  providing  information  to  the  outside. 

This  concept  follows  even  further  where  computation  done  within  the  normal 
access  perimeter  has  interaction  with  the  consoles  outside  either  perimeter. 

SUMMARY/CONCLUSION 

a.  Two  network  control  functions  would  still  result  in  substantial 
communication  between  controllers  or  a great  increase  in  resources. 

b.  There  is  no  security  risk  to  compromising  special  access  data  because 
of  unclassified  network  control  functions  being  performed  and  because 
of  "control -only"  concept  of  communications. 
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TRADEOFF  TITLE 


A81-7  What  is  the  tradeoff  between  the  benefits  of  exact  knowledge  of  task 
timing  and  the  amount  of  resources  needed  to  gather  that  knowledge? 

REQUIREMENTS/BACKGROUND 

Task  scheduling  requires  decisions  as  to  which  tasks  to  start,  which  to 
terminate,  and  which  to  temporarily  suspend.  The  information  needed  to  make 
these  decisions  includes  relative  importance  and  a timeliness  requirement  for 
each  task,  and  current  progress  toward  completion  of  each  active  task.  In  the 
present  GWC  system,  this  is  done  through  manual  intervention  by  the  computer 
operators  using  "checklists"  which  contain  the  necessary  information.  These 
checklists  are  prepared  days  in  advance  and  are  based  on  information  gathered 
from  previous  program  runs  which  is  used  to  predict  nominal  running  times  and 
progress  of  programs.  This  method  of  scheduling  places  heavy  responsibility  on 
the  operators,  and  requires  that  they  be  familiar  with  the  functioning  of  each 
of  the  major  programs.  As  the  GWC  system  becomes  larger  and  more  complex,  this 
method  of  scheduling  will  become  increasingly  inadequate  and  will  eventually 
have  to  be  abandoned.  This  will  be  due  to  the  variety  of  configurations  which 
may  be  established  ad  hoc,  and  the  varying  interference  between  tasks  which 
contend  for  shared  resources.  It  will  become  increasingly  necessary  to  obtain 
and  use  knowledge  of  the  current  state  of  the  system  and  progress  of  active 
tasks  in  performing  the  scheduling  function. 

DESIGN  APPROACHES/CHARACTERISTICS 
(See  ANALYSIS) 

ANALYSIS 

To  satisfy  the  requirement,  each  program  which  operates  in  the  system  must 
provide  progress  reports  to  its  supervising  executive.  A standard  method 
must  be  formulated  for  this  report,  which  would  presumably  be  conveyed  to 
the  executive  via  a subroutine  call.  The  executive  must  maintain  a table  of 
the  progress  of  each  task  within  its  jurisdiction.  The  network  control 
program  must  be  able  to  retrieve  this  information  from  any  executive  on 


request,  and  associate  it  with  data  which  it  retains  on  each  of  the  existent 
tasks  of  the  system.  The  latter  would  include  real  time  requirements  for  the 

task,  and  a nominal  profile  of  progress  against  which  the  actual  progress  can 
be  compared. 

Network  control  must  also  have  information  regarding  the  status  and  use  of 
dedicated  and  shared  resources  assigned  to  tasks.  Dedicated  resources  would 
include  both  physical  components  (e.g.,  tape  drives)  and  logical  components 
(e.g.,  main  memory  sections,  and  auxiliary  scratch  storage),  and  the  status  of 
such  should  be  dynamically  recorded  (i.e.,  assigned,  reserved,  or  free). 
Utilization  of  shared  resources  should  be  maintained  by  hardware  and/or 
software  monitoring  for  busy/idle  information  which  the  scheduling  function 
can  use  in  determining  where  resource  capacity  is  available  for  additional 
tasks.  It  should  be  maintained  on  an  individual  task  basis  if  the  scheduling 
function  is  expected  to  be  able  to  reduce  the  load  on  certain  resources  to 
enable  critical  tasks  which  are  running  late  with  respect  to  their  nominal 
profiles  to  be  placed  bac<  on  schedule. 

These  requirements  can  be  satisfied  on  some  of  the  large  computers  by  including 
code  in  the  executive  to  read  out  timers  or  clocks  which  have  sufficient  pre- 
cision to  permit  measuring  of  processor  and  other  resource  assignments.  If  we 
assume  that  the  load  on  processing  for  this  function  must  not  increase  the 
running  times  of  programs  by  more  than  0.1%,  and  that  an  average  of  100  micro- 
seconds is  required  to  read  out  and  record  the  time  lapse  for  an  executing 
task,  the  function  should  not  be  performed  more  often  than  10  times  per  second. 
This  rate  is  easily  achievable  for  the  GWC  model  programs  which  make  relatively 
infrequent  I/O  demands  for  the  amount  of  computation  performed.  Data  base 
maintenance,  reporting,  and  display  programs  may  push  this  limit,  but  if  timing 
does  become  a serious  problem  for  some  critical  program,  the  period  measurements 
could  be  suspended. 

If  the  computer  does  not  have  a built-in  clock  or  timer  with  sufficient 
resolution  (e.g.,  on  the  order  of  a microsecond),  it  is  recommended  that  an 
auxiliary  addressable  timer  with  the  necessary  resolution  be  obtained  and 
attached  to  the  computer.  As  a last  resort,  an  independent  probe  could  be 
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attached  to  the  computer  to  measure  CPU  idle  time  (as  indicated  by  a "wait" 
processor  state).  This  is  a less  satisfactory  approach  since  it  does  not 
provide  processor  utilization  by  task,  and  will  still  require  acceptability 
by  the  executive  or  the  network  control  function  for  read-out  and  interpreta- 
tion either  on  an  interrupt  or  sampling  basis. 


i 


SUMMARY/CONCLUSIONS 

A fairly  complex  analysis  and  feedback  capability  is  required. 

Each  programming  task  will  provide  progress  reports  to  its  supervisor; 
this  information  is  in  turn  provided  to  network  control  as  a statistic. 

There  will  be  clocking  of  processor  associated  functions  to  provide 
statistics  on  system  utilization. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 
A527-5,  8,  A831-11 


TRADEOFF  TITLE 


A81-8  What  should  be  the  depth  of  responsibility  of  the  network  controller  to 
the  scheduling  of  processors  in  a multi -processor  configuration? 

REQUIREMENTS/BACKGROUND 

One  of  the  advantages  of  a multi -processor  is  the  ability  of  the  executive  to 
utilize  both  processors  to  a maximum  advantage  in  a tightly  coupled  environment. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  network  controller  can  treat  a multi -processor  as  two  individual 
processors  or  as  a unit. 

ANALYSIS 

The  direct  scheduling  of  each  processor  or  even  the  prediction  of  expected  job 
allocation  by  the  Network  Control  function  seems  to  be  a waste  of  resource  and 
an  unnecessary  function.  There  appears  to  be  no  cost  or  efficiency  advantage 
to  be  gained. 

SUMMARY /CONCLUSIONS 

The  network  controller  should  schedule  the  multi-processor  as  a unit,  but 
taking  into  account  the  increased  capability  in  terms  of  its  prediction  algor- 
ithms. The  Network  Control  function  should  never  try  to  assess  individual 
elements  of  a multi -processor  running  as  a unit.  Resource  scheduling  should 
never  go  below  the  level  of  that  unit.  The  network  control  should,  however, 
take  into  account  when  the  two  sides  are  operating  as  a unit  uniprocessor 
or  in  the  event  of  malfunction. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 


A813-11 
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TRADEOFF  TITLE 


A82-1  What  are  the  advantages  of  maintaining  the  lowest  security  levels? 
REQUIREMENTS/BACKGROUND 

A tentative  decision  was  made  to  maintain  the  lowest  security  level  possible. 
This  goal  might  result  in  added  software  costs  involved  in: 

a.  downgrading  data  or  a system,  or 

b.  communicating  between  systems  of  different  security  levels. 

DESIGN  APPROACHES/CHARACTERISTICS 

a.  Retain  present  procedure  of  permanent  system  security  level,  minimum 
automated  security  downgrade,  and  substantial  manual  downgrade. 

b.  Establish  a method  where  both  software  and  systems  are  maintained  at 
the  lowest  level  possible  (and  supported  with  the  additional  software 
to  accomplish  this). 

ANALYSIS 

Under  the  present  system,  far  more  computation  is  done  above  the  classification 
security  level  required.  This  often  results  in  a necessary  manual  downgrade  of 
data  resulting  in  security  problems.  At  other  times  the  downgrade  is  diffi- 
cult if  not  impossible. 

If  data  are  kept  at  a low  level,  then  the  only  data  to  be  upgraded  are  those 
absolutely  necessary.  Several  advantages  result.  Manpower  is  saved  since  the 
checking  function  is  reduced  to  the  absolutely  required  classified  output. 

There  will  be  far  more  computation  accomplished  at  the  unclassified  level 
(probably  more  than  90%)  resulting  in  a more  efficient  scheduling  of  resources 
and  consequently  fewer  resources  required  to  meet  peak  load  requirements  (as 
much  as  a whole  processor  may  be  saved). 

The  disadvantages  are  a more  difficult  scheduling  problem  and  a more  complex 
software  design. 
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SUMMARY/CONCLUSIONS 


We  conclude  that  this  step  is  a cost  savings  and  well  within  the  grasp  of 
current  data  system  design  under  the  proposed  configuration. 

Software  will  be  modularized  and  design  will  be  accomplished  to  accommo- 
date the  capability  to  perform  computation  at  the  lowest  security  level 
possible  consistent  with  modularity  and  network  control  efficiency. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special  Activities  - All 
200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 

RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


A82-2  Are  more  than  two  levels  of  protection  required  within  the  normal  access 
perimeter? 

REQUIREMENTS/BACKGROUND 

In  the  current  system  mixed  mode,  computation  is  essentially  accomplished  at 
two  levels:  unclassified  and  others.  This  results  in  having  to  treat  all 
classified  computations  as  Top  Secret  until  downgrade  certification  can  be 
accomplished  manually, 

DESIGN  APPROACHES/CHARACTERISTICS 

The  approaches  are  to  accommodate  two  levels  or  all  levels. 

ANALYSIS 

In  the  two-level  approach,  we  are  leaving  the  responsibility  on  the  software 
to  insure  that  a message  marked  Confidential  going  out  over  a data  link  really 
does  not  contain  any  Top  Secret  information.  The  only  other  alternative  would 
be  to  treat  the  information  as  Top  Secret  throughout  processing  and  then  down- 
grade it  prior  to  release,  but  this  downgrade  would  hav;  to  be  visual  under 
the  current  security  groundrules.  We  feel,  therefore,  that  although  the 
design  problems  are  greater,  we  should  go  to  a multi-level  system.  The  impact 
of  this  decision  would  be  great  if  we  did  not  have  a network  scheduler  and  a 
rapid  clean  and  switch  capability  which  optimizes  the  time  at  which  the  system 
must  be  at  a classified  level  when  there  was  demand  for  such  resource  at  a 
lower  classified  level.  The  problem  for  the  network  control  function  is  only 
slightly  worse  than  it  would  have  been  otherwise. 

SUMMARY/CONCLUSIONS 

We  should  accommodate  within  the  design  all  levels  and  in  fact  provide  for 
added  compartmentalization  if  required. 
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This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special^Activities  - All 
200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 

RELATED  SPECIFICATIONS 
A821-1 


TRADEOFF  TITLE 


A82-3  Shall  the  design  accommodate  a future  secure  operating  system? 
REQUIREMENTS/BACKGROUND 

The  security  approach  identified  in  this  design  is  almost  entirely  hardware  and 
does  have  a mixed  mode  aspect  in  the  routing  of  communications  as  well  as 
requiring  significant  manpower  for  downgrade  certification. 

DESIGN  APPROACHES/CHARACTERISTICS 

We  can  minimize  cost  by  not  trying  to  produce  a design  which  will  be  compatible 
with  what  we  expect  to  be  the  final  solution  to  mixed  mode  environment  or  we 
can  investigate  the  current  approaches  and  arrive  at  a system  which  is  com- 
patible but  will  impose  additional  cost  to  the  data  system. 

ANALYSIS 

There  are  two  primary  elements  within  the  data  system  which  must  be  isolated  to 
insure  mixed  mode  secure  operations  within  a single  processor  environment:  The 
first  is  an  executive  which  cannot  be  compromised  and  the  second  is  a data  base 
manager  which  cannot  be  compromised.  The  eventual  solution  will  be  code  which 
will  probably  be  executed  by  an  independent  set  of  computer  functions  maintained 
in  a separate  protected  memory  and  have  no  possibility  of  intervention  from 
the  outside  world.  Although  there  are  some  processors  which  have  such  capa- 
bilities, they  have  not  been  bought-off  nor  do  they  have  the  other  character- 
istics which  are  required  in  our  architectural  design.  We  suspect  that  the 
hardware  capability  will  not  be  a simple  add-on  feature  no  matter  what  computer 
we  select,  and  that,  in  fact,  a whole  new  hardware  procurement  must  be 
accomplished  to  attain  such  features.  Even  with  these  features,  there  is  no 
solution  to  the  mixed  mode  environment  of  data  coming  in  over  the  comnuni cation 
line  so  that  solutions  under  those  conditions  are  no  better  than  the  proposed 
architecture. 
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SUMMARY/CONCLUSIONS 
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We  conclude  that  there  is  no  advantage  to  pursuing  a design  to  accommodate 
a secure  operating  system  and,  therefore,  will  not  consider  this  in  our 
design. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

100  - Special  Activities  - All 
200  - Command  Control  Systems  - All 
300  - Emergency  War  Order  Support  - All 
500  - Space  Environment  Support  - All 

RELATED  SPECIFICATIONS 
A821-14 


TRADEOFF  TITLE 


A82-4  What  performance  measurement  software  is  required? 


REQUIREMENTS/BACKGROUND 

Performance  measurements  become  necessary  when  the  system  begins  to  show  signs 
of  strain  in  handling  the  applied  workload.  The  purpose  of  such  measurement 
is  to  determine  where  resources  are  not  being  effectively  utilized,  and  hence 
where  excess  capacity  may  exist.  In  order  to  make  use  of  data  obtained  by 
performance  measurement,  it  is  also  necessary  to  correlate  utilization  with 
the  workload. 


DESIGN  APPROACHES/CHARACTERISTICS 

The  idea  of  performance  measurements  closely  ties  in  to  a data  gathering 
requirement  discussed  in  the  data  storage  area:  collection  of  data  base  usage 

statistics. 


ANALYSIS 

The  characteristics  which  should  be  monitored  in  performance  measurement 
include: 

a.  frequency  of  retrieval  from  identifiable  segments  of  data  bases, 

b.  frequency  of  update  of  identifiable  segments  of  data  bases, 

c.  maximum  and  average  backlogs  of  requests  for  access  to  data  bases 
and/or  data  base  storage  units, 

d.  main  memory  sectional  access  via  Monte  Carlo  methods,  and 

e.  idle  time  fraction  for  central  processors. 


Measuring  software  should  be  incorporated  as  an  integral  part  of  the  operating 
system,  to  be  activated  and  deactivated  either  by  programs  (which  may  be  clock 
driven)  or  by  manual  request.  Thus,  a function  such  as  that  provided  by 
DMGOST  in  the  present  GWC  system  could  gather  statistics  on  data  base  usage 
for  periods  during  which  specific  tasks  are  performed.  In  similar  fashion. 


\ 

request  backlogs  and  memory  references  could  be  sampled  and  tallied  for  specific 
tasks  or  combinations  of  concurrent  tasks.  The  measurement  of  idle  time  for 
processors  could  be  handled  via  a hardware  probe  which  records  wait  status  of 
a processor  and  which  can  be  queried  by  software.  If  it  must  be  done  entirely 
by  software,  it  will  be  necessary  to  factor  out  the  effect  of  the  monitoring 
and  recording  software  in  order  to  determine  the  true  processor  utilization 
under  normal  operation. 

Additional  programs  should  be  developed  to  process  the  data  collected  by  the 
measuring  software,  and  to  prepare  reports  which  indicate: 

a.  whether  update  or  retrieval  should  be  the  principal  factor  in 
determining  the  organization  of  data  bases, 

b.  which  data  bases  should  be  associated  or  disassociated  among  the 
auxiliary  storage  units  (e.g.,  disks)  to  minimize  contention  for 
resources  among  tasks, 

c.  which  blocks  of  data  or  programs  are  referenced  infrequently  while 
in  main  memory,  and  hence  are  likely  candidates  for  roll-in- 
roll-out, 

d.  where  additional  redundant  paths  for  data  transfer  may  be  beneficial 
to  overall  performance,  and 

e.  which  combinations  of  concurrent  tasks  can  most  fully  utilize  the 
central  processors. 

SUMMARY/CONCLUSIONS 

The  data  gathered  by  such  measuring  software  can  be  used  to  modify  the  workload 
schedule  for  the  system,  the  system  configuration,  the  distribution  of  data 
among  the  auxiliary  storage  units,  or  the  programs  which  are  employed  in 
performing  GWC  tasks. 
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RELATED  REQUIREMENTS 


This  Tride  Study  is  related  to  the  following  requirements 
No  requirements. 


RELATED  SPECIFICATIONS 


A527-3  through  9 
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TRADEOFF  TITLE  V._./  J 

A83-1  How  will  phaseover  from  the  '77  baseline  to  the  new  data  system  be 
accomplished? 

REQUI REMENTS/BACKGROUND 

Operations  during  phaseover  cannot  be  interrupted,  and  there  will  be  no 
additional  space  available,  other  than  that  specified  for  the  final  system. 

There  will  be  certain  functions  in  the  current  system  which  will  eventually  be 
deleted  but  must  be  kept  operational  while  phaseover  is  accomplished. 

DESIGN  APPROACHCS/CHARACTERI STI CS 

There  seems  to  be  only  one  option:  that  of  performing  the  phaseover  in  very 

small  increments,  taking  advantage  of  the  flexibility  of  the  new  system  and 
accomplishing  this  before  the  full  load  of  new  requirements  is  due. 

ANALYSIS 

The  first  step  will  be  to  develop  a prototype  system.  This  system  will  consist 
of  one  of  each  major  component  to  be  included  in  the  final  system.  A develop- 
ment center  will  be  established,  preferably  inside  AFGWC  if  there  is  room.  If 
no  room  is  available  at  GWC,  then  the  prototype  system  will  be  developed 
outside,  probably  at  a contractor  facility. 


The  communications  system/ terminal  interface  will  be  developed  next.  A duplicate 
system  will  be  installed  side-by-side  with  the  present  one  and  phased  in  through 
a trial  run  philosophy.  The  primary  difference  between  the  new  system  and  the 
old  system  will  be  in  the  switching  logic  which  will  separate  the  incoming 
traffic  into  separate  paths  according  to  classification  instead  of  all  messages 
being  routed  directly  into  System  I. 


The  next  step  is  to  provide  new  system  components  which  are  functionally  the 
same  as  those  in  the  old  system.  Each  computer  system  within  the  old  configura- 
tion will  then  be  replaced,  one  computer  at  a time  with  the  identical  functions. 
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This  is  assumed  to  be  possible  since  there  will  be  an  over-abundance  of 
capability  at  the  time  of  phaseover;  however,  there  is  the  possibility  that 
it  will  be  necessary  to  procure  certain  required  components  for  the  purposes 
of  phaseover  and  then  deleting  them  again  as  soon  a'  the  system  can  be  brought 
into  operation. 

Auxiliary  functions  which  have  no  new  system  counterpart  will  be  run  on  as  few 
resources  as  possible.  These  will  probably  be  located  in  the  SX  area.  If 
this  is  so,  a manual  security  downgrade  function  will  be  required  during  the 
phaseover. 

Installation  of  a network  control  capability  will  be  the  next  step.  Until 
actual  transfer  of  functions  to  the  new  network  control,  operations  will  con- 
tinue to  be  scheduled  in  the  current  manner.  During  this  period,  a redistri- 
bution of  classified  functions  must  be  accomplished.  This  will  be  one  of  the 
most  difficult  parts  of  the  phaseover  activity.  This  must  begin  to  take  place 
as  soon  as  the  new  processors  are  brought  into  the  system,  and  will  require 
extensive  planning.  In  addition,  it  may  require  some  program  modification  to 
current  software. 


Final  steps  of  the  phaseover  establish  the  automated  work  centers.  When  all  of 
the  consoles  are  connected,  the  system  will  be  complete  and  provide  complete 
automation. 

SUMMARY/CQNCLUSIONS 

Phaseover  can  indeed  be  accomplished  in  a smooth  non-interference  manner  by 
application  of  the  basic  procedure  described  above. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 
A831-1  through  12 
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TRADEOFF  TITLE 


A84-1  What  is  the  requirement  for  system  usage  prediction/simulation? 

REQU I REM^NTS/BACKGROUND 

Scheduler  knowledge  of  future  run  requirements  results  in  efficiency.  The  more 
efficiency  the  less  resource  is  required  to  accommodate  peak  load.  Prediction 
and  simulation  routines  are  costly  in  resource,  expensive  to  build  and  some- 
times are  not  very  accurate  in  a dynamic  system. 

DESIGN  APPROACHES/CHARACTERISTICS 
(See  REQUIREMENTS/BACKGROUND) 

ANALYSIS 

Prediction  of  system  usage  via  simulation  could  reasonably  be  expected  to 
yield  useful  results  if  performed  on  a gross  level  such  as  that  depicted  in 
the  currently  employed  "checklists".  However,  the  predictions  would  have  to 
be  rough,  and  would  not  include  any  significant  effort  at  optimization,  since 
the  effort  required  to  simulate  in  sufficient  detail  to  consider  impact  of 
shared  resources  such  as  processors  and  data  base  access  paths  would  be  a 
costly  process  (in  terms  of  computer  resources  utilized)  and  would  likely  not 
operate  within  real-time  constraints  (discrete  simulation  is  notoriously  time 
consumi ng). 

However,  any  practical  plan  for  utilizing  resources  to  the  fullest  extent  must 
depend  upon  some  automated  form  of  prediction,  and  a rough  scheduling  technique 
which  depends  upon  previous  experience  with  programs  to  be  scheduled  and  the 
resources  which  must  be  dedicated  or  shared  for  their  performance,  would  seem 
to  be  necessary.  This  scheduling  should  be  done  periodically,  on  an  automatic 
basis,  and  manual  requests  for  reruns  with  modified  parameters  should  be 
permitted. 


280 


SUMMARY/CONCLUSIONS 


RPHRRRHHHMHHi 


IPiPlil 


1 


We  suggest  the  design  of  a prediction  capability  in  the  network  control 
processor.  The  initial  capability  shall  be  the  computation  of  resource 
utilization  using  a network  analysis  technique  with  "expected"  run  characteris- 
tics for  scheduled  functions  and  "expected"  pad  for  unknown  functions.  Pre- 
diction fhould  be  to  a point  in  the  future  where  any  present  task  being 
scheduled  might  conceivably  be  impacted. 

The  minimization  of  security  upgrade  and  switching  should  be  considered  and 
conflicts  against  the  status  quo  should  be  optimally  resolved. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 
No  requirements. 


RELATED  SPECIFICATIONS 


TRADEOFF  TITLE 


A84-2  What  simulation  models  should  be  incorporated? 

REQUIREMENTS/BACKGROUND 

Simulation  models  of  a system  as  complicated  as  GWC's  may  be  a useful  tool  in 
predicting  and  avoiding  scheduling  conflicts.  The  amount  of  sophistication 
employed  by  a simulation  model  will  determine  the  amount  of  insight  it  will 
provide.  Whether  a simulation  model  should  be  used  and  the  level  of  complexity 
necessary  must  be  determined  for  the  GWC  case. 

DESIGN  APPROACHES/CHARACTERISTICS 
(See  ANALYSIS) 

ANALYSIS 

No  simulation  models  should  be  suggested  other  than  the  scheduling  prediction 
real  time  model  described  earlier.  Operation  of  the  system  for  a period  of 
time  (e.g.,  a week)  can  be  viewed  as  a reasonable  simulation  of  the  system 
operation  for  a subsequent  period.  The  insight  which  can  be  gained  into 
future  system  operation  by  studying  past  operation  would  not  be  significantly 
increased  by  simulation  unless  a major  perturbation  in  system  operation  is 
planned,  and  we  are  already  attempting  to  evaluate  this  situation  through 
simulation. 

SUMMARY/CONCLUSIQNS 

No  simulation  models  should  be  suggested  other  than  the  scheduling  prediction 
real  time  model  described  earlier. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 

RELATED  SPECIFICATIONS 


A813-7 
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TRADEOFF  TITLE 

A85-1  How  are  present  software  development  techniques  to  be  brought  under  a 
structured  programming  discipline  (e.g.,  modularization,  strict 
standards,  level  of  abstraction)? 

REQUIREMENTS/BACKGROUND 

Structured  programming  reduces  the  number  of  programmers  required  for  mainten- 
ance by  lowering  the  error  rate  of  software  written  under  this  discipline. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  formal  discipline  of  mandating  that  all  future  program  coding  be  restricted 
to  the  use  of  structured  programming  provides  an  opportunity  to  improve 
productivity.  Initial  resistance  to  accepting  such  a discipline  appears  to  be 
small.  As  programmers  use  structured  forms  and  experience  the  advantages,  the 
requirements  for  monitoring  of  program  coding  to  assure  adherence  to  the 
discipline  should  be  minimal. 


ANALYSIS 

Independent  sets  of  existing  code  which  must  remain  intact  in  the  new  environ- 
ment are  treated  as  entities  within  a structured  software  system.  The  rules 
that  are  laid  down  for  new  coding  and  for  the  structuring  of  the  code  must 
then  accept  these  entities  under  the  constraints  of  the  system,  but  on  the 
other  hand,  internal  to  the  entities  there  need  not  be  compliance. 


What  are  the  elements  of  the  structure  that  are  applied  against  the  programming 
task?  The  first  is  a hierarchical  structure  of  function  where  each  step  in  the 
hierarchy  outlines  a more  detailed  representation  of  the  tasks  that  are  per- 
formed by  the  software.  These  functions  are  stated  independent  of  the  control 
that  must  be  imposed  on  the  modules  of  the  software  system.  They  assume 
existence  of  data  elements  on  the  basis  of  need.  Tfaey  are,  as  much  as  possible, 
equal  in  terms  of  level  of  detail  and  size  of  job  to  be  performed.  Simultan- 
eously with  the  functional  hierarchy  a data  base  structure  is  developed  along 
with  a philosophy  for  its  use.  Through  an  iterative  process  the  data  base 
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references  in  the  final  level  of  the  hierarchy  are  made  to  correspond  to  the 
data  base  structure  description.  The  next  thing  to  be  developed  is  a set  of 
level  of  abstractions  which  dictate  responsibility  in  terms  of  resource  control 
and  task  control.  Once  the  levels  of  responsibility  have  been  defined  and  the 
resources  of  the  system  identified  with  levels  and  the  packing  order  in  terms 
of  control  are  established,  the  executive  control  structure  may  be  designed 
and  imposed  on  the  lowest  level  of  task  as  described  in  the  hierarchical 
structure. 

It  must  be  remembered  that  the  elements  of  this  functional  representation  as 
well  as  main  elements  of  the  data  base  description  are  distinct  entities  of 
present  software.  This  will  present  an  imbalance  of  levels  and  a lack  of  homo- 
geneity and  detail  but  it  is  still  key  to  the  integration  of  old  and  new 
software  where  a structure  is  superimposed. 


The  next  essential  step  in  the  design  process  is  the  documenting  of  the  system 
standards  to  be  imposed  on  each  of  the  programming  areas.  These  are  the  sets 
of  rules  that  the  programmers  must  follow  and  the  guidelines  in  terms  of  inter- 
face which  are  necessary  in  a structured  environment.  Two  final  documents  are 
key  in  the  design  process  and  must  be  developed  on  a system-wide  basis.  The 
first  is  a compendium  of  mathematical  equations  used  throughout  the  system 
presented  not  in  programmer  language  but  in  strict  mathematical  notation.  The 
second  document  is  a user  interface  document  which  describes  the  human  engineer- 
ing aspects  of  the  design  at  each  operator  position.  This  develops  a philosophy 
of  operation  and  a statement  of  task  and  considers  the  interface  long  before  the 
code  actually  exists.  All  of  these  documents  are  living  documents  and  should  be 
updated  as  the  design  progresses.  Now  and  only  now  can  the  actual  software 
flowcharting  and  specification  documentation  begin.  If  the  initial  parts  of 
this  job  have  been  done  correctly,  the  development  task  will  be  much  easier. 

The  other  parts  of  structured  programming  such  as  the  chief  programmer  team 
concept,  the  training  of  programmers  (see  below),  the  methods  of  coding  and  the 
use  of  testing  principles  for  checkout  all  are  implemented  independent  of  the 
fact  that  the  system  is  one  which  augments  a previous  system  as  opposed  to  being 
completely  new  and  independent  programming. 
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Rotation  of  personnel,  while  complicating  phaseover  to  chief  programmer  team 
organizations,  can  be  used  to  facilitate  the  AFGWC  transition  to  the  other  new 
methods  discussed  in  that  training  in  the  new  methods  should  be  aimed  at 
incoming  new  officers  who  are  scheduled  to  be  assigned  to  software  development 
activities  rather  than  on  on-site  personnel  who  have  been  trained  in  other 
methods  or  personnel  slated  for  on-the-job  training  and  maintenance, 
modification  and  software  support  assignments.  With  this  approach  all  first 
time  programmers  at  AFGWC  will  be  indoctrinated  within  two  years.  This  type 
of  transitional  training  for  phaseover  to  new  methods  avoids  major 
perturbations  of  the  training  activity  in  that  it  provides  for  transition  of 
programming  courses  from  one  small  course  teaching  new  methods  of  software 
development  (presumably  somewhat  new  and  different  techniques)  into  an 
integrated  portion  of  the  total  AFGWC  programmer  training  program  two  years 
later  using  appropriate  training  techniques  which  have  had  two  years  to  mature. 

" 

1 

SUMMARY/CONCLUSIONS 

Present  software  can  be  brought  under  a structured  programming  capability  in 
an  orderly  phaseover  that  should  not  lead  to  major  problems  for  GWC. 


RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements: 


602  - General  - Manpower  Productivity 

RELATED  SPECIFICATIONS 
A321-11 , A323-2,  A324-2 
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TRADEOFF  TITLE 

A85-2  How  can  maintenance  of  existing  software  be  enhanced  and  new  software  be 
produced  more  effectively? 

REQUIREMENTS/ BACKGROUND 

Although  there  are  a large  number  of  programming  personnel  at  GWC,  the  program 
production  and  maintenance  effort  is  a formidable  one.  In  the  future, 
expectations  are  that  the  need  for  more  effective  software  production  and 
management  techniques  will  be  essential.  Two  primary  reasons  are: 

a.  Indications  are  that  although  GWC  is  now  operating  at  well  below  its 
authorized  staffing  level,  the  number  of  available  skilled  program- 
mers will  decrease,  rather  than  increase.  This  will  be  primarily 
due  to  a dwindling  supply  of  qualified  Air  Force  personnel  in  these 
areas. 

b.  Ever-increasing  numbers  of  new  user  requirements  are  being  levied  on 
GWC,  requiring  the  generation  and  management  of  many  new  models, 
data  handling  routines,  and  numerous  other  programs.  Attendant  with 
this  expansion  of  GWC  responsibilities  is  the  prospect  of  a much 
more  sophisticated  computer  configuration,  requiring  more  complex 
software  for  network  control,  security  management,  communications 
monitoring,  and  the  like. 

To  keep  pace  with  expected  new  requirements  for  GWC  support,  major  improvements 
to  software  productivity  are  essential. 

DESIGN  APPROACHES/CHARACTERISTICS 

In  assessing  potential  methods  for  improvement  of  programmer  productivity,  SDC 
has  given  particular  attention  to  three  potentially  fruitful  areas: 

a.  Assessment  of  personnel  performance  factors, 

b.  Use  of  structured  programming  techniques,  and 

c.  Use  of  interactive  programing. 
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The  conclusions  drawn  in  these  three  areas  are  not  dependent  on  a specific 
data  system  architecture,  nor  are  there  conflicts  between  these  topics;  that 
is,  recommendations  resulting  from  the  analyses  can  be  implemented  individually 
or  in  total  without  conflict. 


ANALYSIS 

Studies  and  analysis  involving  personnel  selection  and  motivation,  structured 
programming  techniques,  and  interactive  programming  are  as  follows: 

a.  Individual  Performance  Factors 

The  productivity  of  individual  programmers  is  highly  variable.  A 
study  conducted  by  SDC  in  1959  showed  that  the  ratio  of  worst  to 
best  productivity  covered  a very  wide  range  for  experienced 
programmers  supposedly  at  the  same  skill  level  (see  Table  8.1). 


Table  8.1.  Personnel  Productivity 


Performance  On 
Debug  Time  Used 
Computer  Time  Used 
Coding  Time 
Code  Size 
Running  Time 


Worst :Best 
26:1 
11:1 
25:1 
5:1 
18:1 


The  most  significant  variable  that  can  be  manipulated  to  increase 
productivity  is  the  improvement  of  this  ratio.  The  gap  between  best 
and  worst  can  be  narrowed  by  selection  of  personnel,  assignment  of 
tasks,  improvement  measurement  of  productivity,  training  and  indi- 
vidually tailored  motivation.  Narrowing  of  the  range  of  productivity 
should  also  improve  estimation  of  schedules. 


The  selection  of  personnel  at  GWC  is  constrained  by  standard  Air 
Force  duty  assignment  practices.  However,  a change  to  partial 
contract  software  development  would  enable  some  freedom  in  this 
area. 
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Individuals  show  considerable  variability  in  their  approach  to  work 
based  on  the  interest  they  have  in  the  subject  matter  and  its 
relationship  to  other  areas  of  interest.  This  variable  cannot  be 
ignored  in  any  attempt  to  maintain  high  productivity,  and  some 
formal  workable  mechanism  must  exist  for  shifting  of  people  between 
groups  based  on  their  desires.  Programmers  generally  have  a high 
intelligence  level  and  become  bored  with  routine.  It  is  important 
to  recognize  the  symptoms  of  this  ennui  and  to  be  willing  to  pay  the 
short-term  price  to  maintain  long-term  efficiency.  The  author  of  one 
type  of  code  (I/O  routine,  compiler,  etc.)  should  not  be  doomed  to 
repeat  a similar  effort  continually  for  new  projects  because  he  is 
"best  at  it"  and  can  "do  it  faster"  than  a new  man. 

The  key  to  all  improvement  is  an  accurate  and  fair  method  of  measuring 
productivity.  The  method  has  to  contain  room  for  a subjective  assess- 
ment of  the  difficulty  of  the  job,  an  estimate  that  should  be  agreed 
on  by  both  the  manager  and  the  programmer  before  and  after  the  job  is 
done.  The  productivity  should  be  broken  down  by  categories  such  as 
those  in  Table  8.1,  with  agreement  on  the  phase  boundaries.  Programmers 
should  be  ranked,  and  the  ranking  should  be  a prime  factor  in  promotion. 
The  ranking  should  be  a closely  guarded  confidential  list,  but  the 
individual  programmer  should  be  made  aware  of  areas  of  exceptional 
performance,  and  of  areas  needing  improvement,  at  periodic  review 
times. 


Training  can  be  used  to  close  the  gap  between  best  and  worst  by 
increasing  the  homogeneity  of  approach  to  software  development,  and 
by  adding  to  the  skills  of  inferior  programmers.  Most  coders  learn 
by  imitating  their  superior  during  the  early  stages  of  their  career 
and  so  the  skill  of  a programmer  is  the  result  of  a random,  uncontrolled 
process.  If  he  doesn't  come  in  contact  with  a good  example,  he  may 
never  invent  the  methods  on  his  own.  Executive  functions  are  often  a 
mystery  to  applications  programmers  and  tend  to  be  a large  bottleneck 
in  degbugging.  Programmers  without  operating  system  knowledge  often 
debug  by  intuition  and  by  inserting  extra  test  code  when  enough 
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1 information  is  already  present  in  a core  dump.  The  problem  is  that 

they  can't  interpret  it  or  trace  the  flow  of  control  block  pointers. 
Sometimes  the  lack  of  assembler  programming  hinders  FORTRAN  coders 
in  reading  a dump.  In  addition,  programmers  are  often  afraid  to 
admit  their  ignorance  by  asking  questions,  especially  when  they  have 
risen  to  senior  status  just  by  the  passage  of  time. 

Motivation  of  individuals  in  the  GWC  environment  becomes  the  respon- 
sibility of  the  immediate  supervisor.  Due  to  the  rigid  promotion 
practices  and  salary  levels  of  the  Air  Force,  it  isn't  really  feasible 
to  motivate  via  accelerated  promotion  or  monetary  reward.  Hence,  the 
immediate  supervisor  must  motivate  via  interpersonal  relationships 
and  informal  management  practices.  Therefore,  it  is  important  to 
measure  the  success  of  management  as  well  as  the  productivity  of  the 
programmer.  It  is  also  important  to  be  flexible  in  allowing  transfer 
between  groups  for  the  reasons  of  incompatibility  between  management 
and  worker,  without  reprisal.  The  tradeoff  that  must  be  made  is  that 
some  supervisors  succeed  by  being  very  aggressive  and  may  create  short 
term  antagonism.  Evaluation  of  management  success  should  not  only  be 
by  those  above,  but  by  those  below.  The  programmer  should  evaluate 
(anonymously  if  desired)  his  supervisor.  Most  importantly,  action 
should  be  taken  to  evolve  to  the  set  of  most  effective  managers. 

The  most  important  variable  in  productivity,  the  range  of  skill  level, 
is  also  the  most  elusive  to  control.  Composite  design,  structured 
programming  and  interactive  development  (discussed  in  succeeding 
sections)  are  better  defined  than  the  techniques  of  narrowing  the 
range  of  productivity.  All  that  has  been  attempted  here  is  to 
delineate  the  variables  that  may  be  within  the  control  of  GWC 
management. 
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b.  Chief  Programmer  Team,  Composite  Design,  and  Structured  Programming 

Composite  design  and  structured  programming  disciplines  offer 
productivity  improvements  of  about  2 to  1*  (and  may  be  as  high  as 

8 to  1)  at  little  cost.  The  practice  of  structuring  a program  so 
that  it  can  be  easily  understood  and  tested  in  a straightforward 

manner  is  not  new.  The  goal  of  constructing  software  systems  in 
well  designed,  easily  modified  modules  has  also  been  available  for 
some  time.  The  ingredient  which  has  been  added  is  that  these 
methodologies  were  previously  practiced  as  an  art  and  have  now  been 
formally  defined  in  such  a way  that  they  are  now  software 
engineering  disciplines. 

Rome  Air  Development  Center  is  sponsoring  a current  study  to  verify 
the  productivity  enhancement  due  to  use  of  the  chief  programmer  team, 
composite  design,  and  structured  programming.  At  the  completion  of 
the  contract,  RADC  expects  to  get  the  following  products: 

1)  Rules  and  guidelines  for  writing  structured  programming 
software. 

2)  Formal  programming  techniques  as  a function  of  the 
language. 

3)  A study  in  data  structuring  methods  in  a structured 
programming  environment. 

4)  Functional  requirements  for  a Programming  Support 
Library  (PSL). 

5)  Software  document  standards. 

6)  Alternate  methods  of  preparing  program  design  specifications. 

7)  Requirements  for  software  project  management  data  collection 
and  reporting. 

* The  gain  in  programmer  productivity  is  primarily  in  the  code  and  debug 
phases  of  a programming  project.  The  overall  gain  depends  on  the  relative 
length  of  these  phases  compared  the  others,  such  as  design  and  documentation. 
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8)  Job  descriptions  for  members  of  chief  programmer  team. 

| 

9)  Estimating  techniques  on  software  resource  requirements  in  a 
structured  program  environment. 

■I 

10)  Training  course  material  in  the  use  of  structured  programming 
technology. 

Thts  material  should  be  available  for  use  by  GWC  by  mid-1975.  Five 
volumes  of  the  final  set  of  15  have  already  been  published. 

This  technique  of  improving  productivity,  shortening  schedules,  and 
lowering  error  rates  is  receiving  the  attention  of  the  entire 
industry.  Information  on  it  is  abundant,  in  journals  and  from  those 
who  are  transitioning  to  it.  It  is  the  clear  direction  of  the 
industry,  and  represents  a low  risk,  low  cost  way  for  GWC  to  improve 
software  development.  The  lower  error  rates  will  also  decrease  the 

level  of  effort  for  maintenance  of  code*  another  attractive  feature 
for  GWC. 

c.  Interactive  Programming 

In  addition  to  the  formal  structure  of  composite  design,  etc.,  inter- 
active software  development  offers  productivity  gains.  The  gains 
here  are  somewhat  offset  by  additional  computer  costs.  The  size  of 
the  gain  appears  to  be  about  2 to  1*.  (and  may  be  as  large  as  6 to  1 ) 
in  addition  to  the  gain  due  to  structured  programming. 

Interactive  programming  has  been  available  for  many  years  without 
success.  It  has  blossomed  now  primarily  due  to  the  decrease  in 
hardware  cost  and  the  increase  in  total  system  reliability. 


The  gain  in  programmer  productivity  is  primarily  in  the  code  and  debug 
plases  of  a programming  project.  The  overall  gain  depends  on  the  relative 
length  of  these  phases  compared  the  others,  such  as  design  and  documentation. 
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There  are  three  levels  of  interactive  programing:  debugging 
interpreters/compilers,  on-line  execution  of  small  programs,  and 
on-line  creation  of  large  batch  programs.  The  benefit  derived  from 
each  of  these  functions  can  be  evaluated  separately.  Each  instal- 
lation strikes  a different  balance  in  usage  and  its  responsiveness 
to  these  functions.  The  software  to  support  terminals  and  provide 
executive  interfaces  is  vendor  supplied  and  maintained.  Examples 
are  IBM's  Time  Sharing  Option  (TSO)  and  Univac's  Conversational 
Time  Sharing  (CTS/1100). 

SUMMARY/CONCLUSIONS 

Three  major  areas  for  consideration  in  increasing  programmer  productivity  are 
ms  f ol 1 ows : 

a.  Individual  performance  factors  Wide  variations  in  personnel  capa- 
bilities are  often  found  at  a given  skill  level.  At  GWC,  this  can 
be  alleviated  by  well  planned  selection  of  personnel,  periodic 
assignment  to  more  rewarding  tasks,  improved  measurement  of 
productivity,  training,  and  individually  tailored  motivation. 

b.  Chief  programmer  team,  composite  design,  and  structured  programming 
This  involves  the  practice  of  structuring  a program  so  that  it  can  be 
easily  understood  and  tested  in  a straightforward  manner.  Rome  Air 
Development  Center  is  sponsoring  a study  to  verify  the  productivity 
enhancement  due  to  these  techniques,  which  represent  low  risk  and 

low  cost  methods  of  improving  software  development  productivity  at  GWC. 

c.  Interactive  programming  Real  time  interactive  techniques  offer 
distinct  possibilities  to  accelerate  GWC  software  production. 

Program  assembly,  routine  debugging,  and  system  tests  can  all  be 
accomplished  in  streamlined  fashion  from  interactive  consoles.  With 
terminal  costs  decreasing  and  manpower  costs  increasing,  this  option 
becomes  an  even  more  viable  technique  to  increase  GWC  software 
productivity  and  maintenance. 
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RELATED  REQUIREMENTS 


This  Trade  Study  is  related  to  the  following  requirements 
602  - General  - Manpower  Productivity 


RELATED  SPECIFICATIONS 


A528-1  through  8,  A52-5 


T 
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TRADEOFF  TITLE 


A86-1  To  what  extent  should  hardware/software  self  diagnosis  be  provided? 


REQUIREMENTS/ BACKGROUND 

Hardware  and  software  reliability  requirements  demand  that  the  possibility  of 
self-diagnosis  be  investigated.  If  a problem  has  arisen  or  indications 
exist  that  it  might,  proper  action  by  the  hardware/software  may  keep  the 
reliability  standards  from  being  violated. 


DESIGN  APPRQACHES/CHARACTERISTICS 
(See  ANALYSIS) 


ANALYSIS 


Reliability  requirements  at  AFGWC  dictate  that  hardware /software  problems  be 
corrected  promptly.  Self-diagnosis  capabilities  provided  with  the  hardware 
which  protect  against  highly  probable  problems  at  a reasonable  overhead  need 
no  justification.  However,  in  some  cases  hardware  reliability  self  checking 
overkill  is  self  defeating  in  that  it  creates  an  overhead  or  causes  additional 
costs  not  merited  by  the  protection  it  provides.  Software  self-diagnosis 
software  can  also  be  self-defeating  if  it  unduly  complicates  software  checkout, 
creates  a high  run  time  overhead,  or  increases  software  development  costs 
beyond  costs  merited  by  the  protection  provided.  Software  statements  which 
are  typical  of  well  justified  software  diagnosis  statements  include:  state- 

ments which  check  the  reasonableness  of  data  which  has  been  calculated  such 
as  a check  for  a negative  attitude;  and  statements  which  prevent  entry  into 
program  blocks  based  on  unexpected  values  such  as  a check  for  a northern 
hemisphere  code  value  and  a check  for  a southern  hemisphere  code  value  as 
opposed  to  code  which  assumes  southern  hemisphere  if  the  code  value  received 
did  not  designate  northern  hemisphere.  No  hardware  diagnostics  logic  should 
be  added  unless  it  has  been  proven  in  the.  field.  No  software  diagnostic 
techniques  should  be  included  unless  they  have  been  proven  to  be  free  of 
problems  and  of  value  in  keeping  the  system  in  reliable  operation. 


( ) 
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9.0  FACILITIES 


TRADEOFF  TITLE 


A93-1  Can  the  hardware  layout  of  future  computer  configurations  conform  to 
the  GWC  facility  space  available? 

REQUIREMENTS/BACKGROUND 

The  current  facilities  being  used  at  AFGWC  will  continue  to  be  used  throughout 
the  time  frame  1977  through  1982.  Although  there  are  plans  for  additions 
to  provide  additional  office  space  for  AFGWC,  the  current  facilities  will 
continue  to  be  utilized  for  sizing  the  computer  systems.  The  baseline  1977 
systems  will  exist  in  AFGWC  as  follows:  Systems  I,  II,  III,  and  IV  will  be  on 
the  main  floor  while  systems  V and  VI  plus  the  data  base  computer  will  be  on 
the  lower  floor.  Thus,  there  are  a large  number  of  rooms  which  have  already 
been  structured  to  house  computer  systems. 


DESIGN  APPROACHES/CHARACTERISTICS 


The  total  facility  floor  space  available  at  AFGWC  is  illustrated  in  Figures  5 
and  6.  The  actual  hardware  layout  using  this  space  has  considered  the 
following  groundrules: 

a.  Allocate  the  rooms  according  to  the  perimeters  required  for  security 
classification  purposes;  these  perimeters  are  designated  Normal 
Access,  Variable  Access,  and  Special  Access. 

b.  Forecaster  and  programmer  console  placements  are  all  approximate 
and  can  be  relocated  to  nearby  areas  without  complication. 

c.  Provide  support  computers  for  and  the  automated  work  centers. 

d.  Isolate  the  printers  where  possible  to  help  lower  the  noise  levels. 

e.  Provide  adequate  space  for  network  control  and  the  operations 
centers. 

f.  Use  Option  C,  Table  10.11  (5-3,  5RP  and  5-50RP  array  processors) 
for  the  hardware  components. 


Q 





299 


Equipment  Areas 


ANALYSIS 


The  following  room  allocations  have  been  determined  to  be  the  most  effective 
utilization  of  the  available  space: 

a.  Normal -acess  perimeter:  rooms  17  and  20  on  the  main  floor  and 

room  L-30  on  the  lower  floor. 

b.  Yariable-access  perimeter:  room  38  on  the  main  floor. 

c.  Special -access  perimeter:  room  43  on  the  main  floor. 

d.  Tape  libraries:  rooms  15,  16,  and  43-A  on  the  main  floor. 

I 

In  addition  to  satisfying  all  the  ground  rules,  the  proposed  hardware  layout 
will  include  the  following  features  (see  Figures  7 and  8): 

a.  Normal -Access  Perimeter  - In  the  room  on  the  main  floor  where  the 
printers  are  located  there  will  be  an  area  designated  for  manual 
disposition  of  the  printer  output.  Also  on  the  main  floor  will 

be  1-3. 5RP  processor,  tape  handling  equipment  and  the  central  data 
base  consisting  of  disks  and  the  mass  storage  facility.  On  the 
lower  floor  the  two  3.5RP  processors  will  be  closely  located  so 
that  it  would  be  possible  to  combine  them  into  a 4 x 4 configuration. 

b.  Variable-Access  Perimeter  - This  will  be  totally  located  on  the 
main  floor  with  all  necessary  equipment  in  one  room. 

c.  Special -Access  Perimeter  - This  will  be  totally  on  the  main  floor. 
The  network  control  console  will  be  located  in  this  area  because  it 
must  have  access  to  all  levels  of  classification.  Because  of  the 
classification  associated  with  this  area,  there  will  be  printers  as 
well  as  manual  tape  drives.  Support  computers  associated  with 
this  perimeter  will  also  be  located  in  this  area. 
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CONTROL 


Figure  8.  GWC  Hardware  Layout  Lower  Floor 


SUMMARY/CONCLUSIONS 

Adequate  GWC  facility  space  is  available  to  house  the  hardware  and  allow  for 
phaseover  involved  in  a typical  future  computer  configuration. 


RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 
601  - General  - Growth 
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TRADEOFF  TITLE 


I 


j 
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AC1-1  What  cost  is  associated  with  the  hardware  and  software  in  the  proposed 
architecture?* 

REQUIREMENTS/BACKGROUND 

This  section  summarizes  the  rationales  that  have  been  applied  to  the  compila- 
tion of  hardware  and  software  cost  elements  of  candidate  GWC  data  system 
architectures.  These  costs  reflect  total  (worst  case)  GWC  requirements,  in 
that  all  user  requirements,  prospective  models,  and  general  system  requirements 
have  been  considered  in  developing  these  figures.  Cost  elements  essentially 
reflect  capabilities  that  will  be  required  in  1982;  that  is,  a growth  in  re- 
quired capabilities  will  be  required  over  the  1977-82  time  period,  with  emphasis 
in  the  1977-1980  time  frame,  culminating  in  maximum  required  data  system  capa- 
bility in  1982. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  costing  approach  has  been  segregated  into  hardware  and  software  acquisition 
costs,  as  follows: 

A.  Hardware 

Five  alternate  hardware  configurations  were  costed,  with  hardware 
components  categorized  into  the  following  areas: 

1.  Processor  subsystems  (including  main  memories) 

2.  Auxiliary  storage  subsystems  (disk  equipment) 

3.  Centralized  data  base  options 

4.  Work  center  subsystems  and  associated  support  processors 

5.  Satellite-unique  processor  options 

6.  Miscellaneous  peripherals  and  components 

•These  costs  are  current  as  of  the  Task  3/4  briefing.  Final  configuration 
costs  appear  in  volume  7 of  the  Final  Report,  section  3.0. 
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Purchase  costs  in  most  cases  were  obtained  from  vendor-supplied  information, 
and  included  sources  such  as  vendor  briefings  and  consultations,  manufacturer's 
literature,  and  SDC's  assessments  of  current  and  projected  component  costs  for 
representative  devices.  Except  as  noted,  monthly  rentals  were  obtained  by 
using  a 40-month  amortization  assumption;  i.e.,  purchase  costs  were  generally 
divided  by  40  to  determine  monthly  rental  charges.  Monthly  maintenance  was 
generally  obtained  by; 

monthly  maintenance  = purchase  cost  x 0.002  x 5 

where  0.002  is  a typical  ratio  for  8-hour  maintenance,  and  a factor  of  5 
is  used  to  provide  7-day-a-week  - 24-hour-a-day  coverage. 

B.  Software 


Software  development  costs  were  obtained  by  categorizing  software  into 
the  following  areas: 

1.  Model  development 

2.  Satellite  processing 

3.  Major  miscellaneous  areas 

Model  sizing  was  based  primarily  on  estimates  provided  by  the  Studies  and 
Analysis  Branch  of  6WC,  as  augmented  by  information  obtained  from  other 
6WC  organizations  (primarily  DO)  and  from  SAMS0.  Satellite  processing 
sizing  was  obtained  from  the  Data  Acquisition  and  Processing  Branch  and 
from  SAMS0  personnel,  while  estimates  for  other  areas  were  generated  by 
various  GWC  organizations  (where  new  user  requirements  could  be  well 
defined)  and  by  SDC  (for  new  capability  areas,  such  as  data  system 
management  and  network  control). 

Associated  dollar  costs  in  1975  dollars  were  based  on  a classification 
of  these  requirements  for  new  code  into  major,  moderate,  and  medium-to- 
low  complexity  efforts,  and  applying  appropriate  dollar-per-instruction 
costs  and  other  pertinent  factors.  A summary  of  these  assumptions 
appears  in  Table  10.1 . 

Conversion  costs  for  existing  software  to  run  on  new  machines  will  vary 
considerably,  depending  on  the  processor  configuration.  Associated 
assumptions  are  as  follows: 
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Table  12,  New  Software  Development 
Cost  Assumptions 


r 


Instruction  costs  -- 

Major  Developments: 

Contractor  Cost  - $30/ Instruction 
Air  Force  Cost  - $20/Instruction 

Moderate  Difficulty: 

Contractor  Cost  - $20/ Instruction 
Air  Force  Cost  - $10/Instruction 

Medium- to- Low  Difficulty: 

Contractor  Cost  - $1 2/Instruction 
Air  Force  Cost  - $ 7/Instruction 


11 

Including  - 
Program  Design 
Prog ran  Coding 

f Parameter  Testing 
System  Validation 
Documentation 


J 


§ 

50%  of  total  effort  performed  by  contractor,  50%  of  total  effort 
performed  by  Air  Force. 


• Hardware-compatible  higher  order  language  used  extensively  - 
assembly  level  language(s)  used  for  control  programs  and  special 
appl i cati ons . 

• Program  coding  includes  interactive  and  structured  programming 
techniques  for  all  but  major  development  efforts. 
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Option  A (Eight  12RP  main  processors) 


a.  UNIVAC  cannot  respond  In  this  processor  range,  requiring 
extensive  software  conversion  costs. 

b.  Mixed  mode  security  will  not  be  required  in  the  3.5RP  machines; 
therefore,  there  should  be  no  inclusion  of  the  cost  of  convert- 
ing RTOS.  The  restructuring  of  the  data  base  will  require  a 
replacement  of  the  machine  language  data  base  routines  after 
1978.  Hence,  no  conversion  costs  are  included  for  any  machine 
language  code. 

c.  Non-UNIVAC  12RP  main  processors  would  not  be  available  until 
1978  for  support  of  requirements.  This  was  based  on  the 
following  conditions: 

• No  competitive  procurement  could  begin  until  after 
completion  of  the  study  (approximately  March  1976). 

• A procurement  would  require  about  a year,  bringing  the 
time  table  up  to  early  1977. 

• The  lead  time  for  main  processors  is  about  6 months  to 

1 year,  which  results  in  an  availability  of  hardware  in 
January  1978. 

Requirements  supported  prior  to  1978  would  have  to  be  coded  for 
UNIVAC  computers  and  converted. 

d.  Conversion  of  FORTRAN  code  from  one  machine  to  another  is 
typically  30%  recode,  60%  modify,  10%  no  change. 

e.  The  existing  system  today  has  about  1 million  lines  of  FORTRAN, 
or  about  5 x 10®  instructions.  About  20%  will  be  replaced  by 
future  code,  leaving  4 x 10®  to  be  converted.  Prior  to  1978, 
approximately  170,000  new  instructions  will  be  written  in  the 
computation  area  alone.  If  this  is  about  80%  of  the  total  of 
new  instructions,  the  number  of  instructions  that  must  be 
converted  is  4 x 10®  + (170,000  -rO.8)  = 4.2  x 10®  instructions. 


312 


No  costs  for  conversion  will  be  incurred  because  SDC  assumes  the 
Air  Force  could  retain  UNI VAC  for  the  3.5RP  machines,  and  that  the 
models  requiring  12RP  capacity  would  not  be  implemented  until  after 
1978,  when  they  could  be  tailored  to  the  12RP  machines.  The  cost 
of  this  new  implementation  is  estimated  as  part  of  new  software 
development. 


3. 


irocessors  rated  at  50RP,  60RP  & 95RP,  respectively) 


A mixture  of  3.5RP  main  processors  and  50  RP  array  processors 
(option  C)  would  require  main  processor  interface  software, 
plus  analysis  of  algorithms  for  vectorization  of  processing. 
(No  interface  software  would  be  required  in  Options  D or  E.) 


Vectorization  software  estimates  were  based  on  Lawrence  Livermore 
Labs'  experience  with  the  CDC  star  Computer  (see  Special-Purpose 
Hardware  foldout  in  the  Task  2 briefing).  The  interfacing  software 
was  estimated  by  SDC  to  be  complex  machine  language  code,  but  may  be 
supplied  (and  not  cost  any  additional  money)  if  the  array  processor 
and  the  main  processor  are  from  the  same  vendor. 


ANALYSIS 

A.  Hardware  Costs 

The  costs  for  processor  subsystems  and  main  memories  vary  considerably 
between  configuration  options.  Estimated  dollar  costs  for  the  various 
classes  of  these  components  are: 
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PROCESSOR  CLASS 


PURCHASE  COST 
PER  UNIT 


TYPICAL  UNIT 


! 


3.5RP 

$ 7.0  x 106 

12RP  (full 

$10.5  x 106 

capability) 

12RP  (reduced 

CO 

ui 

X 

o 

O'! 

capabili ty) 

50RP 

$ 0.5  x 106 

60RP 

$15.0  x 106 

95RP 

$ 2.0  x 106 

UNIVAC  1100/40  2x2, 

IBM  370/168 

| IBM  370/195,  CDC  CYBER  76 

PROTEUS,  UNIVAC  Seismic  Array 
Processor 

STAR- 100,  CRAY-1 

PEPE,  STARAN 


A summary  of  the  main  processor  and  array  processor  costs  associated  with 
the  five  options  initially  selected  is  shown  in  Table  10.2. 


Costs  for  most  of  the  remaining  classes  of  hardware  components  will  be 
essentially  independent  of  the  selected  processor  subsystem  configura- 
tion. (One  exception  is  auxiliary  storage,  where  the  number,  types,  \ 

and  capacities  of  disk  units  and  controllers  will  vary  as  a function 
of  the  type  and  number  of  processor  subsystems.)  Summaries  of  hardware 
component  costs  for  auxiliary  storage,  centralized  data  base  options, 
and  other  categories  of  components  are  presented  in  Tables  10.3  through 
10.7. 


Table  14.  Auxilliary  STorage  Costs 


Vector  CRT 

17 

60 

1.50 

High  Resolution 

22 

1100 

27.50 

CRT 

Color  CRT 

17 

85 

2.13 

Microfilm 

2 

130 

3.25 

Digitizing 

6 

27 

0.68 

Tables 

Interactive 

31  + 30 

186 

4.65 

Term  (ANK  + 
CRT) 

PDP  11/70  Class 

7 

2100 

52.50 

Interface  Processor 

Bare  Support  Processor 

31 

310 

7.75 

Plotter 

10 

150 

3.75 

Pri nters 

100  1pm 

6 

90 

2.25 

1000  1pm 

5 

280 

7.00 

2000  1pm 

5 

435 

10.88 

11000  1pm 

2 

620 

15.50 

Floppy  disk  reader 

4 

32 

0.80 

Remote  Cabling 
TOTALS 

250 

$5855 

$140.14 
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Table  18.  Miscellaneous  Peripheral  Component  Costs 


COMPONENT 

QUANTITY 

PURCHASE 

COST 

($  X 103) 

MONTHLY 
RENTAL 
COST  , 
($  X 103) 

MONTHLY 
MAINT. 
COST  , 
($  X 103) 

CARD  RDR/PUNCH 

4 

150 

4 

1.5 

TAPE  DRIVES  & 
CONTROLLERS 

14 

910 

23 

9.1 

SYMBIONT-TYPE 
PROCESSORS 
(13K  BYTES) 

2 

410 

10 

4.1 

AUTHENTICATION  DEVICES 
(CRYPTO  CHIPS) 

54* 

350 

— 

SWITCHES 

20 

200 

5 

2.0 

TOTALS 

2020 

42 

16.7 

*14-1  way,  40-2  way 
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Software  Costs 

Details  regarding  software  sizing  are  presented  as  follows: 


1 


2. 


Analysis  and  forecast  models 


Based  largely  on  information  supplied  by  Studies  and  Analysis 
personnel,  program  size  estimates  and  related  comments  for  38 
defined  model  capabilities  appear  in  Table  10.8.  Assuming  that 
20%  of  the  total  constitutes  machine  instructions,  this  results 
in  495K  instructions  of  executable  code. 


Satellite  Processing 

These  figures  have  been  derived  as  follows: 
a.  DMSP,  TIROS  Primary  Data:  150K  instructions 

Based  on  35K  new  code  for  gridding  and  mapping  DMSP  fine  data 


b. 


c. 


d. 


and  115K  to  process  TIROS  smooth  data  (36K  for  online  program 
plus  94K  for  a gridder  program,  less  15K  for  reusable  code 
from  DMSP). 

GOES  Primary  Data:  35K  instructions 

Based  on  estimate  supplied  by  GWC  (Lt.  Col.  Coburn). 

TIROS  Secondary  Data:  15K  instructions 

Based  on  5K  instructions  for  each  of  three  unique  secondary 
sensors. 

GOES  Secondary  Data:  15K  instructions 

Based  on  5K  instructions  for  each  of  three  .unique  secondary 
sensors. 


Major  Miscellaneous  Areas 

a.  Product  Request  Processing:  130K  instructions 

Based  on  30K  of  new  code  for  enhanced  CFP  system,  55K  instruc- 


tions for  CFLOS  extraction,  and  45K  to  support  Minuteman. 
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Model  Estimated  Program  Size 
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ETAC,  Carswell  Backup:  10K  instructions 

Based  on  Lt.  Col.  Coburn's  estimate  of  5350  lines  of  object 
code  to  support  six  areas  now  supported  by  ETAC  on  their 
SPECTRA  70/45  and  IBM  360/44  machines,  plus  SDC's  estimate  of 
5K  of  new  instructions  to  provide  the  formatting  and  switching 
functions  performed  by  Carswell.  This  latter  5K  figure  is  based 
on  the  following:  Carswell  new  has  two  1108s  with  a total  capa- 

city of  130K  words.  Assuming  25%  is  allocated  to  operating 
system  use,  this  leaves  about  1 00K  words  available.  Assuming 
20%  of  these  are  instructions,  this  results  in  20K  instructions. 
Of  this  figure,  it  is  assumed  that  only  25%  is  for  unique  code 
that  must  be  implemented  at  6WC  to  support  Carswell  customers, 
for  a net  of  5K. 

Communications  Support:  50K  instructions 

Based  on  the  assumption  that  about  75%  of  the  RT0S  I-bank  total 
of  31. 7K  (25K)  can  be  recoded,  and  that  about  25K  of  additional 
instructions  will  be  required  for  accomplishing  the  new 
security  determination,  decoding,  and  routing  requirements 
of  the  proposed  system. 

Data  System  Management:  80K  instructions 
This  is  based  on  SDC's  assessment  of  the  code  required  in  the 
support  computers  and  main  processors  to  support  quality 
control,  computer  operations,  maintenance,  security  monitoring, 
and  special  operations  functions,  as  well  as  code  for  data 
system  performance  measurement. 

Network  Control:  50K  instructions 

This  is  based  on  code  required  to  support  this  function  in  the 
main  processor,  plus  some  associated  code  in  a system  support 
processor.  Network  control  computations  include,  among  other 
capabilities,  routines  for  system  usage  prediction  simulation. 


f.  Programmer  Support:  20K  instructions 

This  figure  involves  the  estimated  support  for  the  software 
development,  remote  job  entry,  and  studies  and  analysis 
console  functions. 

g.  Interface  Processors  to  Support  Forecaster  Consoles: 

TOOK  instructions 

This  is  based  on  support  to  the  display  and  routing  options 
that  will  be  available  t0  a variety  of  types  of  Forecaster 
consoles,  distributed  among  24  different  consoles  and  two 
interface  processors.  Estimates  have  considered  the  avail- 
ability of  vendor-supplied  software  and  the  possibilities 
for  hardware-driven  displays,  as  well  as  the  requirements  for 
new  software  to  provide  new  requirements. 

A summary  of  the  new  classes  of  programs  that  must  be  so  developed 
appears  in  Table  10.9.  Note  that  over  one  million  instructions  of 
new  code  is  assumed  to  be  required  to  support  model  requirements, 
user  requirements,  and  the  enhanced  automation  features  that  will 
be  obtained  in  these  new  architectures. 

To  provide  a cost  estimate  for  this  new  development,  these  programs 
have,  been  categorized  as  to  expected  level  of  difficulty  in  order  to 
apply  cost  ground  rule:  . The  results  of  this  categorization,  along 
with  the  results  of  applying  costing  algorithms  described  earlier, 
appear  in  Table  10.10.  It  thus  appears  that  for  the  estimated 
program  requirements,  a 50-50  mix  of  contractor  and  Air  Force 
programming  skills  could  conceivably  generate  this  10  words  of  new 
code  for  a cost  on  the  order  of  $20  x 106. 


Table  20.  Required  Program  Development  Summary 
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Instructions 


4.  Conversion  Costs 


t.  Option  A (Eight  12RP  Processor  Subsystems) 

As  indicated  earlier,  the  number  of  instructions  that  must  be 
converted  under  the  eight  12RP  option  is  4.2  x 10^  instructions. 

60%  will  be  modified  at  a cost  of  $1 /instruction  by  USAF 
programmers  familiar  with  the  code,  or 

0.6  * 4.2  (106)*  $1  = $2.5  x 106 

30%  will  have  to  be  recoded  by  USAF  programmers  familiar  with 
the  code  at  $12/instruction,  or 

0.3  * 4.2  (106)*  $12  = $15.1  x 106 

10%  will  not  cost  anything. 

The  total  cost  is  estimated  to  be  $17.6  million. 

This  was  erroneously  presented  as  $7  million  in  the  Task  2 
briefing  due  to  a mi scommuni cation  regarding  the  size  of  the 
existing  GWC  software  base.  The  error  does  not  change,  but 
rather  reinforces,  the  discarding  of  Option  A. 

b.  Option  B (a  mixture  of  3.5RP  and  12RP  Processor  Subsystems) 

No  costs  for  conversion  were  incurred  because  SDC  assumed  the 
USAF  could  retain  UNI  VAC  for  the  3.5RP  machines,  and  that  the 
models  requiring  12RP  capacity  would  not  be  implemented  until 
after  1978  when  they  could  be  tailored  to  the  12RP  machine. 

The  cost  of  this  was  estimated  in  new  software  development. 
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c.  Options  C,  D,  and  E (3.5RP  main  processors  with  array  processors 
rated  at  5QRP,  5QRP,  and  95RP,  respectively) 

A mixture  of  3.5RP  main  processors  and  50RP  array  processors 
(Option  C)  would  require  main  processor  interface  software,  plus 
software  for  analysis  of  algorithms  for  vectorization  of  proces- 
sing. The  software  interfacing  (Option  C only)  was  estimated 
by  SDC  to  be  complex  machine  language  code.  SDC  feels  that 
$2  million  is  a conservative  estimate  for  implementing  the 
interfacing.  In  fact,  this  interface  may  be  supplied  (and  not 
cost  any  additional  money)  if  the  array  processor  and  the  main 
processor  are  from  the  same  vendor.  Vectorization  was  estimated 
for  Options  C,  D,  and  E to  be  $3  million  based  on  Lawrence 
Livermore  Labs'  experience  with  the  CDC  Star  Computer  (see 
Special-Purpose  Hardware  foldout  in  the  Task  2 briefing). 

Thus,  depending  on  the  configuration  selected,  conversion  costs  can 
range  from  zero  (Option  B)  to  $17.6  x 106  (Option  A).  However,  only 
Options  C and  E are  currently  assumed  to  be  viable  alternatives, 
with  conversions  costs  of  $5.0  x 106  and  $3.0  x 106,  respectively. 

The  new  software  development  costs  of  $19.9  x 106  are  assumed  to 
be  independent  of  the  configuration  selected. 

SUMMARY/CONCLUSIONS 

Hardware  acquisition  and  software  development  costs  for  five  potential  configura- 
tions are  summarized  in  Table  10.11.  These  figures  are  based  on  the  assumptions 
and  analyses  described  above,  and  reflect  extensive  assessment  of  state-of-the- 
art  developments. 

Note  that  processor  Options  C and  E are  the  most  attractive  from  an  overall 
cost  standpoint,  while  Option  B can  be  employed  if  these  options  are  not 
realizable.  Option  A has  been  disregarded,  due  to  its  heavy  dependence  on 
Air  Force  programmer  personnel  for  conversion  of  existing  software,  while 
Option  D is  deleted  from  further  consideration  because  of  its  excessively 
high  cost. 
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(5)AUXILIARY  MASS  STORAGE  COSTS  a, IE  BASED  ON  QUANTITIES  TO  SATISFY  THE  OPTION  C CONFIGURATION. 
SOHE  DIFFERENCES  IN  QUANTITIES  AND  COSTS  MOULD  BE  ASSOCIATED  WITH  THE  OTHER  OPTIONS. 


This  Trade  Study  is  related  to  the  following  requirements: 

All. 

RELATED  SPECIFICATIONS 

A90-1,  A93-1,  A932-1  , A933-1,  A934-1  , A911-1,  A912-1,  A931-1' through  8 
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TRADEOFF  TITLE 

AC1-2  What  costs  are  associated  with  the  large  computational  requirements? 


(I.  ) 


REQUIREMENTS/BACKGROUND 


This  trade  study  deals  with  the  hardware,  software,  and  personnel  costs 
associated  with  three  major  requirements: 

a.  Cloud-free  line-of-sight  processing; 

b.  Minuteman  support; 

c.  Satellite  fine  data  processing. 


DESIGN  APPROACHES/CHARACTERISTICS 


Component  costs  associated  with  these  three  requirements  are  based  on  the 
following: 

a.  Hardware 

Assessments  were  made  of  the  impact  of  these  requirements  on  all 
major  categories  of  hardware  entities  (central  processors  and  main 
memories,  mass  storage,  etc.),  and  associated  costs  of  these 
affected  components  were  identified.  Component  costs  so  identified 
were  based  on  the  unit  costs  used  in  determining  total  system  costs 
in  the  Hardware  and  Software  Costing  Tradeoff  Study  (AC1-1). 

b.  Software 

Similarly,  assessments  were  made  of  associated  software  costs  by 
employing  the  sizing  estimates  and  costing  rationale  described  in 
the  Hardware  and  Software  Costing  Tradeoff  Study.  Sizings  of  the 
affected  programs  are  based  on  model  requirements  information 
supplied  by  GWC,  as  augmented  by  additional  information  received 
from  other  GWC  and  SAMSO  personnel. 

c.  Personnel 

Personnel  requirements  were  based  on  data  supplied  by  GWC,  and 
were  Air  Force  estimates  reflecting  assumed  personnel  made  to 


support  these  programs  over  the  1977-82  time  frame.  A net  figure  of 
$30,000  per  man  year  has  been  employed,  assuming  a relatively  senior 
level  mix  of  computer  science  and  meteorologist  skills. 


ANALYSIS 

Presently,  processor  Option  C (five  3.5RPs  and  three  SORPs)  and  Option  E (five 
3.5RPs  and  three  95RPs)  appear  to  be  the  two  most  viable  processor/memory 
alternatives.  The  analyses  that  follow  are  therefore  oriented  towards  these 
two  options. 

1 . Hardware  Costs 

a.  CFLOS  and  Minuteman 

We  estimate  that  CFLOS  would  require  the  equivalent  of  64  wall- 
clock  hours  of  1108  time  per  day,  while  Minuteman  support  would 
require  118  wall-clock  hours  per  day.  If  ei ther  of  these  user 
requirements  are  deleted,  there  would  not  be  enough  of  a reduction 
in  required  support  to  justify  the  deletion  of  one  of  the  large- 
scale  processors;  i.e.,  a 50RP  or  95RP  processor  would  still  be 
needed  to  accommodate  the  other  requirement.  However,  if  both 
CFLOS  and  Minuteman  requirements  are  deleted,  enough  computer  power 
can  be  saved  to  warrant  the  removal  of  one  of  these  machines.  Thus, 
in  Option  C,  the  removal  of  one  50RP  processor  would  save  $500K, 
while  the  deletion  of  one  95RP  processor  in  Option  E would  save 
$2  x 10^.  (A  small  amount  of  mass  storage  can  also  be  saved  by 
deleting  CFLOS  and/or  Minuteman,  but  the  related  costs  are 
insignificant  compared  to  CPU  savings.) 

b.  Satellite  Fine  Data  Processing 

Computer  time  associated  with  satellite  fine  data  processing  from 
DMSP  is  not  enough  to  justify  the  deletion  of  a central  processor, 
if  the  processing  of  satellite  fine  data  is  not  required.  Estimates 
are  that  1 hour  of  1110  2 x 1 wall  time  per  day  will  be  needed  in 
1980,  using  285K  of  main  memory.  There  will,  however,  be  a reduced 
requirement  for  auxiliary  mass  storage.  The  equivalent  of  two 
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UNIVAC  8433  disk  units  (34  x 10b  36-bit  words  each)  can  be  deleted 
if  the  raw  data  are  not  stored,  while  another  two  disk  units  can  be 
deleted  with  the  elimination  of  gridded  fine  data.  One  disk  con- 
troller can  also  be  eliminated.  Net  storage  hardware  costs  for 
either  Option  C or  E are  therefore: 


4 disk  units  0 $36,000 

1 disk  controller  @ $100,000 


$144,000 

$100,000 

$244,000 


(This  was  shown  as  $340K  in  the  Task  2 briefing  where  the  assumption 
was  made  that  two  disk  controllers  could  be  eliminated.) 


Hardware  utilization  is  based  on  the  following  assumptions  (data  are 
assumed  to  be  processed  at  the  available  resolution  of  0.3  nm.;  pro- 
cessing times  are  in  UlllO  2 x 1 units): 


1) 


Raw  data  storage 

a)  34. 7M  (36-bit)  words  per  vehicle 

Support  storage  for  two  vehicles  simultaneously,  resulting 
in  approximately  69. 4M  words  of  mass  storage 

This  is  offset  to  a more  realistic  50M  words,  which  pro- 
vides 1.5  times  one  vehicle  maximum  readout  per  rev. 


b) 

c) 


2) 


Machine  costs 

a)  1978  (3%  of  available  data) 

At  4 min  per  2/5  orbit  and  10  revs/day. 


4 min/rev  x 10  revs/day  = 40  mi n/day/ vehicle 
40  x 2 DMSP  vehicles  = 80  min  of  available  data/day 
80  x 0.03  = 2.5  min  CPU  time,  which  is*  4.2  SUPS  time, 
or  » 18  min  wall  time 
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b)  1980  (10%  of  available  data) 


80  minutes  x 0.10  = 8 min  CPU  time,  which  is  = 14 
min  SUPS  time,  or  = 60  min  wall  time 

3)  Gridded  data  storage 

a)  Coverage  for  8 3DNEPH  boxes 

b)  Reduced  to  0.3  nm  scale 

c)  Six  gray  shades  per  36-bit  word 

d)  IR  and  visual  data 

This  totals  to  45. 0M  words  of  mass  storage 
Software  Costs 

Development  costs  for  new  software  to  meet  these  requirements  are  assumed 
to  be  independent  of  the  selected  configuration.  Computations  are  as 
follows: 

a.  CFL0S 

Assumed  program  size  is  260K  words.  Assuming  20%  of  the  total  are 
executable  instructions,  this  results  in  0.20  x 260K  = 52K  of  in- 
structions to  be  developed.  Employing  the  ground  rules  discussed 
in  the  Hardware  and  Software  Costing  Tradeoff  Study  (a  50-50  Air 
Force-Contractor  mix  to  design,  code,  test,  validate,  and  document 
this  high  complexity  program),  resulting  costs  are: 

Air  Force:  52K  x 0.5  x $20  = $ 520  x 103 

Contractor:  52K  x 0.5  x $30  = $ 780  x 103 

$ 1300  x 103 


b.  Minuteman 

The  assumed  size  and  complexity  of  the  Minuteman  support  software 

C 

is  the  same  as  that  of  CFL0S:  thus,  an  additional  $1.3  x 10  can  be 
saved  in  new  software  development  if  this  capability  is  eliminated. 
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c.  Satellite  Fine  Data  Processing 

Estimates  for  total  program  storage  size  for  fine  data  processing  are 
36K  words  for  the  on-line  routine  and  285K  words  for  the  gridder  pro- 
gram, for  a total  of  321 K words.  Assuming  that  about  90%  of  this 
total  is  for  data  storage,  approximately  10%  (or  35K)  can  be  assumed 
to  be  executable  instructions.  This  code  is  considered  to  be  of  high 
complexity.  In  addition,  5K  of  medium-complexity  instructions  would 
not  have  to  be  developed  in  3DNEPH  to  support  this  requirement. 

Again  employing  the  guidelines  outlined  in  the  Hardware  and  Software 
Costing  Tradeoff  Study,  resultant  computations  are: 


Air  Force: 


Satellite  data  - 

35K  x 0.5  x $20 

= $ 

350  x 

103 

3DNEPH 

5K  x 0.5  x $10 

= $ 

25  x 

103 

Contractor: 

Satellite  data  - 

35K  x 0.5  x $30 

* $ 

525  x 

103 

3DNEPH 

5K  x 0.5  x $20 

* $ 

50  x 

103 

$ 950  x 103 


3.  Personnel  Costs 

Based  on  required  manpower  estimates  received  from  GWC,  and  employing  a 
figure  of  $30,000  per  Air  Force  man-year,  GWC  personnel  costs  to  support 
these  user  requirements  are  as  follows  (personnel  costs  for  these  re- 
quirements are  independent  of  the  selected  architecture): 

a.  CFLOS 

SA  is  expected  to  require  one  additional  position  from  1977-82  to 
support  CFLOS,  while  AD  will  employ  one  more  position  from  1978-82, 
for  a total  of  11  man  years.  Net  cost  is  11  man  years  x $30  x 103/ 
man-year,  or  $330  x 103. 
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b.  Minuteman 

Minuteman  will  require  1 additional  position  in  AD  from  1980-82,  for 
a total  of  3 man-years,  or  a cost  of  $90  x 10  . 

c.  Satellite  Fine  Data  Processing 

No  additional!  GWC  personnel  requirements  are  directly  associated 
with  this  requirement. 


SUMMARY/CONCLUSION 

A summary  of  the  major  hardware,  software,  and  personnel  costs  associated  with 
these  three  requirements  for  Options  C and  E is  shown  in  Table  10.12. 

Note  that  the  deletion  of  CFLOS  and/or  Minuteman  requirements  can  save  from 
$1.4  x 106  to  $3.6  x 106,  depending  on  the  configuration  and  on  whether  or  not 
both  requirements  are  eliminated.  Total  costs  for  Satellite  Fine  Data  Pro- 
cessing would  be  $1.2  x 106,  regardless  of  the  architecture  selected. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

113  - Special  Activities  - Program  D 

115  - Special  Activities  - Agency  B 

120  - Special  Activities  - ZOOM  Use 

305  - Emergency  War  Order  Support  - SAC 

511  - Space  Environment  Support  - OTHB  Radar 


SOFTWARE: 


TRADEOFF  TITLE 

AC1-3  What  is  the  software  cost  of  not  retaining  UNIVAC  1100  computers? 
REQUIREMENTS/BACKGROUND 

Software  which  operates  efficiently  on  UNIVAC  1100  computers  will  not 
necessarily  stand  the  transition  to  some  other  vendor  without  a degradation 
in  performance.  Two  potential  problem  areas  in  particular  involve  the  changing 
of  the  word  size  and  the  incompatibilities  resulting  from  the  different  vendor 
compilers  of  the  same  language.  These  are  costs  which  must  be  evaluated  and 
included  in  software/ hardware  considerations. 

DESIGN  APPROACHES/CHARACTERISTICS 

As  a necessary  first  assumption  to  replacing  the  UNIVAC  1100  computers,  we  must 
assume  that  the  replacements  will  have  a word  size  equal  to  or  greater  than  the 
U 1100s.  If  this  were  not  so,  all  of  the  data  bases  would  have  to  be 
restructured  for  the  smaller  word  size,  and  data  declarations  in  programs  used 
to  pack  and  unpack  the  data  would  have  to  be  altered;  we  consider  this  an 
unacceptable  approach  on  a short-term  phaseover  because  of  the  significant 
costs  and  perturbations  to  current  operation. 

Given  the  above  assumption,  it  would  still  be  necessary  to  modify  FORTRAN 
programs  and  to  completely  rewrite  GWC-produced  assembly  language  programs. 
Assuming  that  the  latter  consists  of  300,000  written  statements,  complete 
recoding  and  checkout  for  a new  computer,  at  an  estimated  30  statements  per 
day,  would  require  10,000  mandays;  for  example,  it  should  be  achievable  in 
about  8 months  by  50  programmers.  If  FORTRAN  coding  has  been  for  the  most 
part  confined  to  a transferable  portion  of  the  FORTRAN  language,  we  should 
estimate  that  at  least  1%  of  the  code  would  require  modification.  This 
amounts  of  10,000  out  of  an  assumed  one  million  FORTRAN  statements  in  the  GWC 
library,  or  500  mandays  of  effort  at  an  assumed  modification  rate  of  20 
statements  per  day. 

Thus,  the  investment  in  assembly  language  code  alone  would  seem  to  rule  out 
the  practicability  if  replacing  the  U 1100  computers  within  a few  months. 


ANALYSIS 


} 


The  information  presented  below  is  an  abridged  version  of  the  total  costing 
analysis: 

a.  RTOS  will  be  discarded  or  rewritten,  in  any  event,  due  to  use  of 
multiple  COMM  front-ends. 

b.  Non- QT VAC  vendor  hardware  would  not  be  available  for  1 year  after 
the  decision  was  made  to  convert  and  decision  would  not  be  until 
after  competitive  procurement,  until  after  end  of  Task  4 or  well 
into  Task  5 (January  1976).  Conversion  could  thus  not  begin 
until  1978.  Therefore,  no  new  models  to  be  implemented  prior  to 
1978  could  be  written  for  the  new  hardware. 

c.  The  percentage  of  the  system  through  1977  that  would  be  replaced 
after  1978  is  about  20%  of  the  FORTRAN  code. 

d.  Data  base  management  code  will  be  completely  replaced  due  to  new 
requirements,  and  can  be  tailored  to  post  1978  hardware. 

e.  Assuming  30%  rewrite,  50%  modification,  and  10%  no  change: 


Minus 

Plus 


* 5.0  x 106 

* 1.0  x 106 

* .17  x 106 

* 4.2  x 106 


instructions  today 

instructions  replaced  by  future  code 
new  instructions  required  prior  to  1978 

instructions 


30%  recode  = 1.26  x 10^  instructions 

60%  modification  = 2.52  x 10^  instructions 


Recode  is  @ $1 2/instruction  for  USAF  programmers,  or 
$15,120,000 


Modification  is  0 $l/instruction  for  USAF  programmers , or 
$2,520,000 

Total  = $17,640,000. 
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SUMMARY/CONCLUSION 

If  UNIVAC  1100  computers  are  to  be  replaced,  it  should  be  through  a phaseover 
process  extending  for  several  years,  and  should  be  integrated  with  reformula- 
tion of  the  pertinent  programs  to  maximize  the  benefit  of  recording,  and 
minimize  the  impact  upon  other  required  GWC  work. 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 
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TRADEOFF  TITLE 


AC1-4  What  is  the  cost  of  redundancy  in  configurations  where  the  variable 
perimeter  is  not  considered? 


REQUIREMENTS/BACKGROUND 

In  a system  made  up  of  special  and  normal  access  areas,  required  backup  power 
to  meet  the  reliability  level  of  0.995  becomes  a major  cost.  The  variable 
access  area  may  be  one  way  of  minimizing  it. 

DESIGN  APPROACHES/CHARACTERISTICS 

A configuration  of  3.5RP  computers  with  array  processors  will  be  used  as  an 
example.  For  the  purpose  of  this  study,  we  will  assume  that  all  functional 
requirements  could  be  met  by  assigning  one  machine  to  the  special  access  area 
and  three  to  the  normal  access  area. 


ANALYSIS 

The  configuration  discussed  above  will  meet  functional  requirements,  but  not 
reliability.  To  achieve  a 0.995  reliability,  two  approaches  can  be  taken: 
one  with  and  one  without  the  variable  perimeter. 


SPECIAL  ' VARIABLE  ; 

ACCESS  j PERIMETER  j NORMAL  ACCESS 


CASE 

I 


CASE 

II 


SPECIAL 

ACCESS 


} 


3ZZ 


> 


NORMAL  ACCESS 
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"conventional" 

processors 

array  processors 


The  big  difference  between  the  two  is  that  while  the  1~3.5RP  machine  and 
array  processor  in  the  variable  perimeter  in  CASE  I can  meet  reliability 
requirements  in  both  the  special  and  normal  access  areas,  an  extra  naif  of 
a 3.5RP  machine  and  array  processor  is  needed  in  Case  II.  This  latter  case 
also  requires  an  additional  disk  unit. 

SUMMARY/CONCLUSIONS 

Deletion  of  the  variable  perimeter  requires  the  following  additional  costs: 

One-half  of  a 3.5RP  processor 

One  disk  unit  \ Up  to  $5.8M 

One  array  processor  ) 

RELATED  REQUIREMENTS 

This  Trade  Study  is  related  to  the  following  requirements: 

No  requirements. 
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TRADEOFF  TITLE 


AC1-5  What  is  the  cost  tradeoff  associated  with  an  automated  and  centralized 
network  control  capability? 

REQUIREMENTS/BACKGROUND 

If  the  network  control  capability  is  to  be  automated,  it  should  be  located  in 
a centralized  area  where  it  can  monitor,  and  if  necessary,  control  the  health 
of  the  entire  system.  It  must  be  determined  whether  such  a concept  is  cost 
effective. 

DESIGN  APPROACHES/CHARACTERISTICS 

The  network  control  facility  will  be  assumed  to  be  an  automated,  centralized 
capability  physically  located  in  the  special  access  perimeter  due  to  security 
considerations. 

ANALYSIS 

There  are  three  primary  factors  which  make  automated  network  control  cost 
effecti ve: 

th®  latent  flexibility  in  its  design  provides  for  inexpensive 
reliability, 

b.  it  would  take  a much  larger  system  to  meet  the  time  requirements 
of  individual  functions  without  a dedicated  or  automated  network 
control  capability, 

c.  the  increase  in  efficiency  resulting  from  automated  network  control 
potentially  amounts  to  two  or  three  processors  which  is  a several 
million  dollar  saving. 

SUMMARY/CONCLUSIONS 

An  automated  and  centralized  network  control  capability  would  be  a cost 
effective  investment  for  GWC. 


Appendix  A 
ALPHABETICAL  INDEX 


Topic 

array  processors,  linked  to  more  than  one  host 

array  processors  for  models 

array  processors  vs  multiple  computers 

Q 

associative  memory  (10  bit) 
associative  processor  for  data  management 
authentication  chips  and  switches 
authentication  and  switching  of  components 
automatic  mass  storage  systems 
batched  processing 

backup,  network  control  and  central  data  base  management 

control  only  data  connection 

communication  links  buffering 

communication,  one  way 

communications  processors ) 

communication  responsibilities  (AFGWC  vs  AFCS) 

cost  of  hardware  and  software 

cost  of  large  computational  requirements 

cost  of  network  control 

cost  of  redundancy 

cost  of  software  without  Uni  vac  1100  computer 

data  base,  distributed 

data  base  hardware 

data  base  hardware,  overlay 

data  base  interface,  demand  vs  service  vs  update 

data  base  management 

data  base  processor  transfer  of  data 

data  base,  single  control 

data  base  structure 

data  base  structure,  knowledge  by  applications  programs 
data  base  update  and  read,  simultaneous 


A-l 


Tradeoff 

Number 


31-3 

1 

30-9 

1 

•■I 

30-8 

11-7 

13-12 

22-3 

1 

22-2 

11-6 

J 

32-3 

31-4 

21-1 

\ 

m 

11-5 

22-1 

31-5,  44-1 

1,  44-5  1 

40-1,  40-2 

AC1-1 

AC1-2 

AC1-5 

AC1-4 

AC1-3 

13-8 

10- 5 
13-2 
13-5 
31-2 
24-1 
13-1 
13-9 
13-7 

11- 1 


M 

4 


_ . Tradeoff 

Topic  Number 

data  management  system,  vendor  produced  13-13 

data  packing  13_4 

data  structuring,  generalized  13-11 

editing  incoming  data  44-3 

editing  outgoing  messages  40-7 

facsimile  systems  interface  46- 1 

forecast  consoles  52-1 

functions,  centralizing  81-4 

functions,  mini-processor  31-5 

functions  on  dedicated  processors  30-10 

functions,  splitting  up  large  30-11 

hardware  layout.  93- 1 

interfaces,  incompatible  24-2 

interfacing  costs  between  vendors  30-2 

interface  standardization  of  communications  query/response  40-5 

intercommunication  20-1 

1/0  rates  40_6 

keyed  data  entry  devices  10-3 

language,  data  oriented  16-6 

languages,  higher  order  36-2 

line  handler  decoder  router  44.5 

message  certification  44.4 

message  logging  4O-4 

message  priority  42-i 

mini -computers  and  complex  incompatible  component  interface  24-3 

multitasking  of  CPU's  81-3 

multiprocessors,  bullpen  backup  31 -4 

network  control,  operations  management  for  81-2 

network  control  systems  81-6 

normal  access  perimeter,  levels  of  protection  in  82-2 

operational  structure  81-1 

output  spool  buffering  H-3 

personnel  requirement  based  on  AWC  design  71-1 

packet  switching  and  security/application  routing  44-6 

A-2 


Tradeoff 

Number 


Topic 

performance  measurement  software 

phaseover 

preformatting  data 

processor  requirements  based  on  functions 
Prre?iabili'tyUirenientS  b3Sed  °n  functions»  security,  and 

programmer  interfaces 

programmer  shortage,  alleviating 

programming.  Air  Force  vs  contractor 

protocol  standardization 

protocol,  total  system 

RTOS  as  router  of  low  level  messages 

RTOS,  upgrade  vs  rewrite 

satellite  data,  analysis  vs  image  storage  for 

satellite  data  compression 

satellite  data  compress ion/ rejection  criteria 

satellite  data  gridding  and  mapping 

satellite  data  prefiltering 

satellite  data  reception,  processing,  and  output  protocol 
satellite  image  compression/rejection,  display  of 
scheduling,  automatic 

scheduling  responsibilities  of  Network  Controller 

secure  operating  system 

security  and  multiprocessors 

security  classification  distribution 

security  levels 

security,  variable  perimeter 

self  diagnosis 

SID  interface 

SID  interface  with  raw  ungridded  data 
simulation  models 
simulation/prediction  usage 


82- 4 

83- 1 
13-10 
30-5 


30-6 

52-2 

70-1 

70-2 

45-1 

29- 1 
40-3 

30- 4 
13-5 
13-3 
10-6 
43-4 
43-1 

29- 2 
51-2 

81- 5 
81-8 

82- 3 

31- 1 

30- 7 

82-1,  82-2 
11-4 
86-1 
43-2 
43-3 
84-2 
84-1 
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I 

I 

Tradeoff 


Topic 

Number 

software  maintenance/production 

85-2 

software,  system  heteorgeneity  impact  on 

30-1 

software,  programmer  support 

36-1 

staging  and  rapid  data  transfer 

10-2 

storage  backup  medium,  cheaper 

11-8 

storage  backup/recovery 

10-4 

storage  support  for  forecaster  consoles 

52-3 

storage  types  and  amounts 

10-1 

structured  programming 

85-1 

SWI  data,  how  it  will  be  handled 

* 

42-1 

variable  perimeter 

11-4 

wall  time  of  GWC  average  functions 

30-3 

WWMCCS  data  base 

13-6 

I 


i 


A-4 


